In my blog entry OFM 11g: Implementing OAM SSO with Forms we set the foundation for providing a complete Single Sign-On solution based on Oracle Access Manager (OAM). This foundation should now be used to combine Forms 11g and ADF Faces 11g applications with a transparent login.

The Beginning

Before we start, lets re-consider the requirements to achieve the ultimate goal. These are:-

1. Access to the Forms 11g Application must be authenticated by OAM (protected).
2. Access to the ADF Faces 11g Application must be authenticated by OAM (protected).
3. Switching from one application to the other should not result in a re-authentication (aka single sign-on).
4. User identity should be availble to the application without any extra work in the application code.

All these are the common requirements for a single sign-on solution. The challenge here is that Forms relies on Oracle AS SSO (OSSO or "the old SSO") while ADF Faces is quite open and can be protected by Oracle AS SSO and Oracle Access Manager SSO (OAM SSO or "the modern SSO"). Both application types can use their own login mechanism.

The Forms 11g Application

To demonstrate the SSO functionality, we use the standard Forms test (/forms/frmservlet?form=test.fmx). Although this shows nothing specific in the Forms application, it is good enough to demonstrate that it is protected.

The ADF Faces 11g Application

With ADF 11g you can develop quite a number of useful Faces based applications. Among many features, it comes with the ADF Security feature that provides you with functionality to protect your pages, regions, and even TaskFlows from un-authenticated usage in a declarative way.

To demonstrate that functionality a sample application with different access levels plus a login dialog is used. This application comes with a publc page that has protected content (a button). Once you are authenticated for the application, the protected content and some personalisation (the users name) is shown.

Protecting Forms 11g

As already explained in the OFM 11g: Implementing OAM SSO with Forms, the easiest way to protect a Forms application is to configure it as a OSSO partner application, setup mod_osso, test it, migrate OSSO to OAM SSO with the Upgrade Agent, reconfigure mod_osso, and you are done.

Sort of. By default the OAM is configured to run in co-exist mode. This means that a user has to re-authenticate to the Forms application when logged into an OAM SSO application before. To avoid this, you must disable the co-exist mode, for example by using WLST and issue the disableCoexistMode on the OAM server.

Protecting ADF Faces 11g

To protect an ADF Faces 11g application we have to consider two scenarios:

1. Use a HTTPD server in front of WLS
2. Use WLS without a HTTPD server

Both scenarios have their pro's and cons' and we won't get into details and just describe how to configure both.

Scenario 1: HTTPD Server with WLS

In this scenario we have to setup the environment in some steps:-

1. Configure a WebGate at OAM
   This configuration can be done through the OAM console or by a script. No matter which way you choose, the WebGate configuration files will be created for you.
2. Install the OAM WebGate into an HTTPD server
   The type of webgate you need to install depends on you HTTPD server. With Oracle HTTP Server 11g you can use the latest OAM 11g WebGate. With other HTTPD servers you must resort to OAM 10g WebGates. A OAM 11g WebGate can use the pre-created configuration files supplied during the WebGate configuration at OAM. An OAM 10g WebGate asks for the specific configuration and verifies it during installation.
3. Configure the WLS plugin to forward the requests to WLS
   Again, depending on your HTTPD Server you have different plugins to forward requests to WLS. With OHS 11g you can use the pre-installed mod_wl_ohs plugin. Its configuration is quite simple and straightforward.
4. Configure an OAM SSPI Provider as a IdentityAsserter in WLS to retrieve the user identifier
   This configuration is quite important as it retrieves the user identifier for the next step. If you have a SOA Suite installation within your OFM_HOME, the necessary software is already installed and you only need to setup your Security Realm within WLS.
   You can do this by pointing your browser to the WLS Console, log in as administrator, select the Security Realm (usually myrealm), and select Providers. We add the OAMIdentityAsserter as the first SSPI Provider. It is important that the Control Flag is set to SUFFICIENT. Every other configuration can be left as is, no changes are necessary here.
5. Configure an OAM Identity Provider to get the real user identity
   In OFM 11g: Implementing OAM SSO with Forms we have configured an OID as Identity Store. To get the user identity we need to configure the same OID as an SSPI Provider for WLS. This will retrieve the real user information from OID and creates the JAAS Subject and Principals to be used by any application within WLS.
   Again, you can do this by pointing your browser to the WLS Console, log in as administrator, select the Security Realm (usually myrealm), and select Providers. Now add the OIDAuthenticator as the second SSPI Provider. It is important that the Control Flag is set to OPTIONAL. After we saved this setup, we need to configure this provider by setting the Provider Specific details to access OID.

Scenario 2: WLS only

This scenario is a bit easier but requires more work in the WLS setup:-

1. Configure a WebGate at OAM
   This configuration can be done through the OAM console or by a script. No matter which way you choose, the WebGate configuration files will be created for you.
2. Configure the OAM SSPI Provider as IdentityAuthenticator to authenticate and set the user identifier
   When using the OAM SSPI Provider as OAMAuthenticator we create it with the Control Flag as SUFFICIENT. Afte saving it, the Provider Specific settings must be configured to allow the OAM SSPI Provider to connect to the OAM Server.
3. Configure an OAM Identity Provider to get the real user identity provider
   Again, you can do this by pointing your browser to the WLS Console, log in as administrator, select the Security Realm (usually myrealm), and select Providers. Now add the OIDAuthenticator as the second SSPI Provider. It is important that the Control Flag is set to OPTIONAL. After we saved this setup, we need to configure this provider by setting the Provider Specific details to access OID.

Configure ADF 11g Application for OAM

Actually, there are no changes to be made within the ADF application. We only need to add the value CLIENT_CERT to the <auth-mode> tag in the <login-config> tag in the web.xml file.

Testing

To test the configuration, simply point your browser to one of both appliction URLs. OAM should kick in and redirect you to the OAM Login page. After you have entered the correct credentials, access to the URLs is granted and you will see the application.

Enjoy!