Oracle Applications DBA Blog

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.