Oracle Applications DBA Blog

Configuring Single Sign On With Oracle Application (Linux AS)

In my last post i has discussed about Single Sign On in Oracle Applications, This post focuses on detail step by step instructions for configuring single Sign On With an existing Oracle Applications Instance.
This is assuming that you already have a Oracle Applications instance and a 10 G Application Server instance installed.

System Overview

Oracle Applications
Version 11.5.10.2
OS: Redhat Linux
Type: Single Node instance (Node A)
Applications OS User: applsam
Database OS User : orasam
Instance SID: SAM
Host: Node A
Port Pool: 23

10g Application Server
Version: 10.1.2.0
OS: Redhat Linux
Infrastructure with the following configured components
OracleAS Metadata Repository
Oracle HTTP Server
OracleAS Containers for J2EE
Oracle Internet Directory
OracleAS Single Sign-On
OracleAS Delegated Administration Service
OracleAS Directory Integration and Provisioning
OS user for infrastructure: saminf
ORACLE_HOME: /u01/sam/saminf/OraHome
ORACLE SID: SAMAS
Host: Node B

Task: To implement SSO with Oracle Applications.

Pre requisite for Oracle Applications

Check the Apache version of your Oracle Applications on Node A

Log in as the applications user 'applsam'
$cd $IAS_ORACLE_HOME/Apache/Apache/bin
$./httpd -v
Server version: Oracle HTTP Server Powered by Apache/1.3.19 (Unix)
Server built:   Feb 22 2005 18:51:19 (iAS 1.0.2.2.2 rollup 5)

If the version reported is less that 1.3.19 then you must apply Oracle9i Application Server Release 1.0.2.2.2 CD Pack.

Autoconfig

Make sure that your Oracle Applications is autoconfig enabled

DBMS_LDAP on E-Business Suite

Check if the DBMS_LDAP package is installed in your applications database.
Login is as the database user 'orasam'
$sqlplus "/ as sysdba"
SQL*Plus: Release 9.2.0.6.0 - Production on Fri Nov 3 10:23:38 2006
Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.6.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.6.0 - Production
SQL> desc DBMS_LDAP;

If the package does not exist create it using the catldap.sql located in $ORACLE_HOME/rdbms/admin/ as SYSDBA

Pre requisite for Oracle Application Server 10g

Release 10.1.2

If the version of Applications server is not 10.1.2 you must upgrade your 10 g application server to 10.1.2.0

Test OIDDAS

Log into to OIDDAS as orcladmin user and create a test user to test the working of your application server installation.

http://<hostname>.<domain>:<http port>/oiddas

Implementing SSO

E-Business Suite SSO 10g Integration Patch

Apply the E-Business Suite SSO 10g Integration Patch (4775907) to your Oracle Applications using adapatch. Before applying the above patch make sure that all the pre requisite patches specified in the patch readme are applied.

Execute the SSO registration script in Oracle Applications.

The SSO registration script is a perl script and registers your E-Business Suite with SSO and OID. It prompts for a list of parameters which you should have ready.

Parameter List

Hostname of 10g AS: samlnx03.appsdbablog.com
Port Of Application Server DB : 1521
Application Server Database : samas
OID LDAP Port : 3060
APPS user password : apps
Password for the ORASSO User : I0ds305V

(You can use the ldapsearch script located in the $ORACLE_HOME/bin/ of your Application Server 10g instance or from your Oracle Directory Manager client software, i use the client as its easy)

Password for the SYSTEM user of Oracle Application DB : manager
Password for the 'SSOSDK' on your Oracle Applications DB : SSOSDK

(The user will be created if it does not exist)

Password for the OID admin user orcladmin : admin123
Password with which you wish to register your E-Business Suite with OID :admin123
A valid Provisioning Profile Template : The default is ProvBiDirection.tmp,you can find additional templates at $FND_TOP/admin/template/

The SSO registration script by default uses a ProvBiDirection.tmp provisioning profile which is a BI directional Provisioning template, you can also provide a different provisioning template.

Additionally you must ensure that the perl from your IAS_ORACLE_HOME is in your application users profile and the version is 5.005 or higher.
$ which perl
~/samora/iAS/Apache/perl/bin/perl
$ perl -v
This is perl, version 5.005_03 built for i686-linux
Copyright 1987-1999, Larry Wall

Execute the txkrun.pl script

$ txkrun.pl -script=SetSSOReg
Enter the host name where Oracle iAS Infrastructure database is installed ? hcslnx03.satyam.com
Enter the Oracle iAS Infrastructure database port number ? 1521
Enter the Oracle iAS Infrastructure database SID ? samas
Enter the LDAP Port on Oracle Internet Directory server ? 3060
Enter Oracle E-Business apps database user password ? apps
Enter Oracle iAS Infrastructure database ORASSO schema password ? I0ds305V
Enter Oracle E-Business SYSTEM database user password ? manager
Enter E-Business Suite existing SSOSDK schema password or choose a password to use with the new SSOSDK schema if the schema does not exist ? ssosdk
Enter the Oracle Internet Directory Administrator (orcladmin) Bind password ? admin123
Enter the instance password that you would like to register this application instance with ? admin123
*** ALL THE FOLLOWING FILES ARE REQUIRED FOR RESOLVING RUNTIME ERRORS
*** Log File = /u02/sam/applsam/samcomn/rgf/SAM_hcslnx08/sso/txkSetSSOReg_Fri_Nov_3_15_27_47_2006.log
Program : /u02/sam/applsam/samappl/fnd/11.5.0/patch/115/bin/txkSetSSOReg.pl started @ Fri Nov  3 15:29:53 2006
*** Log File = /u02/sam/applsam/samcomn/rgf/SAM_hcslnx08/sso/txkSetSSOReg_Fri_Nov_3_15_27_47_2006.log
######################## WARNING
This application works with SSOSDK version 9.0.2 or higher. If lower version
(3.0.9) of SSOSDK was installed in your system and you have a registered
partner application, this process will remove the 3.0.9 version of the SSOSDK
schema and install the 9.0.2 version.
######################## WARNING
Beginning input parameter validation for SSO registration.
Beginning loading SSO SDK into database if necessary.
Loading of SSO SDK into database completed successfully.
Input parameter validation for SSO registration completed.
Beginning input parameter validation for OID registration.
Input parameters validation for OID registration completed.
BEGIN SSO REGISTRATION:
Beginning to register partner application.
Partner application has been registered successfully.
Single Sign-On partner application registered successfully.
BEGIN OID REGISTRATION:
Beginning to register Application and Service containers if necessary.
Application and Service containers were created successfully.
Beginning to register application in Oracle Internet Directory.
Registration of application in Oracle Internet Directory completed successfully.
Beginning to register instance password in Oracle Internet Directory.
Registration of instance password in Oracle Internet Directory completed successfully.
Beginning to test application registration in Oracle Internet Directory.
Testing of  application registration in Oracle Internet Directory completed successfully.
Beginning to register provisioning profile in Oracle Internet Directory.
Registration of provisioning profile in Oracle Internet Directory completed successfully.
Application is now registered successfully with provisioning in Oracle Internet Directory.
End of /u02/sam/applsam/samappl/fnd/11.5.0/patch/115/bin/txkSetSSOReg.pl : No Errors encountered

Add your 10g AS to the list of trusted nodes in your E-Business Suite

With 11.5.10 and higher you need to add the 10 G application server mode as a trusted node withing your E-Business suite You can do this through your Oracle Applications Manager Oracle Applications Manager=>Applications Dashboard=>Security=>Manage Security Options. You need to run autoconfig after this and bounce your database listener.

Restart your HTTP listener.

Restart your Apache HTTP listener to have your SSO registration take effect.

You may need to apply additional patches based on the E-Business Suite products installed.

Posted by Sam at 12:49 PM | Permalink | Comments (3) | TrackBacks (0)

Implementing Single Sign On in Oracle Applications

In a default configuration of Oracle Applications the user validating and sign on is done at the database level. For this purpose the FND_USER database table is used.

This how a native Sign - On in Oracle Applications will typically work

• The user types in the Oracle Applications URL in his web browser.
• He enters his username and password.
• A connection is made by the application to the database using the database listener and the applsyspub username. The password for this user should always be default which is 'pub'.
• Next the username and password entered by the user are validated against the information present in the FND_USER table.
• After this the user Authorization is performed and the user is given access to the responsibilities that he has been assigned.

In case of implementing single sign on the job of authentication is delegated to a Lightweight Directory Access Protocol (LDAP) server. This LDAP server can either be Oracle Internet Directory (OID) server or any other third party LDAP server.

One of the main advantages of this kind of implementation is that multiple application can be integrated with the same LDAP server thus requiring the user just to sign in once and access all these application. Also since most of the organizations might already have an existing LDAP server running they may want to use the same for the purpose of this authentication.

Sometime ago i had read a interesting distinction between authentication and authorization in Steven Chan's blog. According to which the authentication is the process of user validation and authorization is the process of identifying what resources (responsibilities) are to be allocated to that user.

In a Single Sign-On (SSO) architecture while the process of authentication is delegated to the LDAP server, the authorization process is still handled by the Oracle Applications database.

Under the Single Sign On architecture, E-Business suite is registered as a partner application within the SSO server. As  a result once the user authenticates himself within the SSO server he can access all the partner application registered with that SSO sever. Also logging out of any of the partner application logs out the user out of all the partner applications.

In a Single Sign - On environment the sign on would happen in the following steps.

• Once the user navigates to the E-Business suite URL a check is made for a valid 11i cookie.
• If this not present it is assumed that the user had not logged any partner application and is presented with the Single Sign  On screen.
• The user enter is SSO username and password which is sent for validation against the information that is present in the LDAP  server.
• Once validated the user authorization takes place against the FND_USER table in the oracle applications database and the user is presented with the resource he has been allocated.
• The user can navigate to any partner application which have been registered with the SSO server.

To implement a Single Sign On with Oracle Application you must at minimum implement the following.

• A 10g Application Server with Oracle Single Sign-On (SSO).
• A LDAP server like Oracle Internet Directory (OID) or any other Third party LDAP solution.

You may use a third party Single Sign - On solution also but under such a configuration you would still require to implement Oracle Single Sign  - On, under such a situation the third party SSO actually becomes a partner application to your Oracle SSO just as the E-Business suite is registered as a partner application.

Another important fact is that implementing 10G application server does not result in upgrading the 9i Application server  that comes with the standard Oracle applications 11.5.10.The 9i Application Server would still be a core component of the technology stack and just the configures services are delegated to the 10G Application Server.

User Synchronization.

Under a SSO architecture the user information is stored under two places , one in the oracle applications database and the  other in the LDAP server. A user might be created in OID and it maybe required to have the user propagated to the E-Business suite. Similarly users may be created in e business suite and they would have to be then propagated to OID.
To address these issues there are a provisioning options which we can set up by using provisioning profiles.

In a typical SSO implementation we have with us three options.(E-Business with OID)

Option 1: Provision E-Business Suite to Oracle Internet Directory
Under this we set up all user created in a E-Business suite will automatically be provisioned to the OID.

Option 2: Provision Oracle Internet Directory to E-Business Suite
Under such a situation all the users are created within the OID after which they are provisioned automatically to the E-Business suite with a predefined responsibility.

Option 3: Bi directional Provisioning Between E-Business Suite & Oracle Internet Directory
This option allows the users to be created in either the business suite or the OID. Regardless where they are created they are provisioned either to the E-Business Suite or OID depending on the case.

DMZ environment and SSO.
Until recently multiple entry points in E-Business suite were not supported in a SSO configuration. That is if you have a OID in the intranet it would be able to authenticate your internal user but will not be able to do the same for the external  users. In such a case we had to either use two different OIDs, one for the intranet and one of the internet and the  synchronize the information between both the OIDs which was a big pain. The other ways was to allow the external/internal 
users to use the native authentication method via FND_USER and allow SSO only on the intranet.
But as of ATG Rollup 4 multiple E-Business entry points have now been supported, bringing the much need relief :)

Another new feature is that as of SSO build 4.0 its is now also possible to have a Secure Sockets Layer (SSL) configuration in your Single Sign On server.

Posted by Sam at 05:34 PM | Permalink | Comments (11) | TrackBacks (0)