Facts about Implementing SSO in Oracle Application Servers

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.

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.

In Next blog let us discuss about steps to implement Oracle SSO in details