You can upgrade an existing OracleAS SSO 10g Release (10.1.2.0.2) through OracleAS SSO 10g Release (10.1.4.3.0) to Oracle Access Manager 11g. This chapter explains the co-existence that is provided when upgrading OracleAS 10g SSO (OSSO) to use Oracle Access Manager 11g SSO. It includes the following sections:
See Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management for upgrade steps.
Oracle uses the term "upgrade" when referring to moves between Oracle product versions and technologies. For instance, a move from OC4J to Oracle WebLogic Server is an upgrade; moving from OracleAS 10g SSO to OAM 11g SSO is an upgrade.
Oracle uses the term "migration" for moves from a non-Oracle technology stack to an Oracle technology stack.
The Oracle-provided Upgrade Assistant scans the existing OracleAS 10g SSO server configuration, accepts as input the 10g OSSO policy properties file and schema information, and transfers configured partner applications into the destination Oracle Access Manager 11g SSO.
A typical OSSO deployment includes a number of OSSO servers with a front-end load balancer. All OSSO servers in the cluster have the same back-end store. The load balancer routes authentication requests to any OSSO servers in the cluster.
Co-existence requires OAM 11g and OSSO 10g to use the same back-end user identity store: Oracle Internet Directory (OID). OAM 11g co-exists with the single OSSO Server or cluster of OSSO servers. Dynamic redirection must work as expected for applications protected by OSSO 10g and OAM 11g.
During the upgrade process, partner applications registered with OSSO 10g are transferred to OAM 11g along with associated Oracle HTTP Server Agents, corresponding host identifiers, and other details. OAM 11g is added to the front-end load balancer of existing OSSO 10g Servers.
If an existing OSSO 10g configuration has out-of-the box configurations that cannot be mapped directly, an Administrator must manually transfer these after automated upgrade processes finish.
After upgrading, OAM 11g co-exists with either a single OSSO Server or cluster of OSSO servers. Existing partner applications (including Portal, Forms, Reports, and Discoverer) start using Oracle Access Manager 11g as the SSO provider. The load balancer routes some of the authentication request to the OAM Server while the rest continue to be served by the existing OSSO 10g Servers. Once the user is authenticated by either the OSSO 10g or OAM 11g Server, the user can access any of the partner applications without having to re-authenticate.
For more information, see "Pre- and Post-Upgrade Topology and Authentication Examples".
This section provides the following topics:
A typical OSSO set up has a number of OSSO Servers with a front-end load balancer. All OSSO Servers in the cluster have the same back-end user identity store. The load balancer routes authentication requests to any of the OSSO servers in this cluster, as shown in Figure A-1.
Figure A-2 illustrates a simple situation where the OHS (Partner) front-ends the protected application. OHS (OSSO) is the front-end proxy Web server protecting the OC4J OSSO application server host. This is needed only if there is an OSSO OC4J server behind it.
After upgrading the environment is configured to use Oracle Access Manager 11g for authentication.
Upgrading to OAM 11g starts by installing a new OAM 11g Server and transferring the partner applications to this OAM Server.
One of the existing OSSO Servers is brought down. The OAM 11g Server replaces the downed OSSO Server and the load balancer starts routing authentication requests to the newly added OAM 11g Server (and continues routing authentication requests to remaining OSSO 10g Servers).
Over time, each of the OSSO 10g servers should be replaced by OAM 11g Servers.
The upgraded OSSO set up is shown in Figure A-3.
To provide Single Sign On for the user to access any of the partner applications, OAM 11g accepts the user authenticated by OSSO server as an authenticated user. Also, when OAM 11g validates a user it also sets appropriate cookies that the OSSO server can understand. The OSSO server does not need to validate the user again.
Once the user is authenticated by either OSSO 10g or OAM 11g, the user can access all the partner applications protected by either server. OAM 11g and OSSO 10g set appropriate cookies to achieve single sign on.
OAM 11g creates a session for each request and sets a cookie that contains this session ID. The session represented by this cookie has JAAS subject of the authenticated user among other details.
With OSSO 10g, the server sets a host cookie that contains information about the logged in user.
For additional information, see:
In this post-upgrade view, Oracle Access Manager 11g is used for authentication. The Oracle HTTP Server front-ending the OSSO 10g Server points to the Oracle WebLogic Server where Oracle Access Manager 11g is installed. This means that:
OHS Partner: mod_osso redirects requests to the 11g OAM Server for authentication through a proxy.
Proxy: mod_wl replaces mod_oc4j. mod_wl enables single sign-on to work without any changes on the Oracle HTTP Server side.
Figure A-4 illustrates this post-upgrade topology with mod_wl replacing mod_oc4j.
In this example, the proxy server that once included mod_oc4j has been eliminated entirely. The Oracle HTTP Server front-ending the 10g OSSO Server points directly to the Oracle WebLogic Server where Oracle Access Manager 11g is installed.
Figure A-5 illustrates this topology, which most deployments will use.
This section provides the following topics:
Figure A-6 illustrates authentication by OAM 11g SSO in an upgraded environment where OAM 11g co-exists with OracleAS 10g SSO. Details follow the figure.
User accesses a partner application that has been upgraded from OSSO 10g to OAM 11g.
The load balancer routes the user's authentication request to the OSSO 10g server, which serves the login page. After successful authentication, OAM sets the SSO cookie and updates session information accordingly. The cookie includes a flag indicating that an OSSO cookie must also exist for this cookie to be valid.
When the user accesses an application protected by OSSO 10g an OSSO 10g cookie is already set in the browser, and the user is not challenged for credentials and can access the application.
Both the OAM 11g and OSSO 10g cookie must be kept in sync. Any session information that is updated in the OSSO 10g cookie must be synchronized with the OAM 11g cookie and vice-versa.
As shown in Figure A-6, the user accesses the partner application and the user's authentication request is routed to OSSO 10g by the load balancer. Here, the OSSO server displays the login page and after collecting and validating user credentials, only the OSSO cookie is set in the user's browser.
When the user accesses the partner application protected by the OAM 11g server, the OAM Server must first check if a valid OSSO cookie already exists before displaying the login page.
If a valid OSSO cookie exists already, the OAM 11g server must create an OAM 11g SSO cookie from the OSSO cookie. The OAM Server configuration has a flag which says whether the coexist mode is enabled or not. If the coexist mode is enabled, then the OAM Server looks for the OSSO cookie to be present along with OAM 11g Server's SSO Cookie. This flag can be either turned on manually in the configuration followed by a server restart or a WLST command can be used to turn the coexist flag on/off.
When the user logs out of a partner application and the logout request is routed to the 10g OSSO Server, the 10g OSSO Server deletes the OSSO cookie. With coexistence enabled, with both 10g SSO and 11g OAM Servers behind a loadbalancer, the partner information is shared by all the Servers (10g OSSO or 11g OAM Servers). Therefore, associating one of the servers (10g or 11g) with the partner application is not correct. During the upgrade, all the partner information is also migrated to the 11g OAM Server.
After the OSSO Cookie has been deleted, if the user tries to access a protected application, and if the request this time goes to the OAM 11g Server, only the OAM Server's SSO Cookie is found. The Server learns from the coexist flag in its configuration that the setup is in coexist mode. In coexist mode, the OSSO cookie needs be present for the OAM11g Server Cookie to be valid. Hence the login page is thrown and the user is asked for validation.
The OAM 11g server must make sure that the session information in both the OSSO and OAM cookies are in sync.
This section provides the following topics:
The following topics provide information that help you locate transferred OSSO 10g details in the Oracle Access Manager Console:
Details of the sample partner applications that use OSSO 10g are provided here to help you compare the OSSO 10g configuration with the upgraded configuration for Oracle Access Manager 11g.
Table A-1 shows the applications protected by OracleAS 10g OSSO.
|Application Name||Host||Oracle Home|
Oracle Portal (portal)
OSSO 10g configuration details for each application includes administrator-assigned:
Home Page URL
Date range for which login to the application is allowed by the server
OSSO 10g configuration also includes:
Unique Application ID
Application Token used by the partner when requesting authentication
Encryption Key used by the OSSO Server to identity the application
Single Log-Out URL
For each application in the OracleAS 10g SSO deployment (Table A-1), there is an Oracle HTTP Server instance. Each OHS instance transfers as an OSSO Agent that is named after the application. In the Oracle Access Manager Console, you can locate each transferred OSSO Agent configuration under the System Configuration tab, Agents node in the navigation tree.
Figures in this topic illustrate the transferred OSSO Agent configurations for the applications identified in Table A-1. Each generated Agent configuration is named as the application it protects.
While the 10g Application ID is not recorded in the Agent configuration for OAM 11g, most configuration details are included and remain the same:
Site Token: The application token.
Single Log-Out URL
Figure A-8 illustrates the generated Agent configuration for the first OSSO 10g-protected application. Details were derived from the OSSO 10g Oracle Internet Directory during automated upgrade processing.
Figure A-9 shows the transferred configuration for a second application protected by OracleAS 10g SSO (OSSO).
Figure A-10 shows the transferred OSSO Agent configuration for the third application protected with OracleAS 10g SSO (OSSO).
Figure A-11 illustrates the transferred Host Identifier. It is named
migratedSSOPartners because this is the Application Domain name in which it is used. Details were derived from the OSSO 10g Oracle Internet Directory during automated transfer processing.
Figure A-12 illustrates the Application Domain created during the transfer and the resource definition. Details were derived from the OSSO 10g Oracle Internet Directory during automated transfer processing.
Both the Application Domain and the Resources definition are named
Figure A-13 illustrates the Authentication Policy, named
Protected Resource Policy, for the Application Domain
The default OAM 11g authentication scheme is used: LDAPScheme.
You can use the following steps to confirm that single sign-on is occurring in the upgraded environment using Oracle Access Manager 11g.
Perform steps in "Validating Post-Upgrade SSO with Oracle Access Manager Protected Resources" to confirm that OAM 11g protected resources are being accessed through OAM 11g.
Stop the Oracle HTTP Server on the computer that is hosting the 10g OSSO server.
Restart the 11g OAM Server.
In the Oracle Access Manager Console:
System Configuration, Agents: Confirm that the upgraded 10g partner applications have appropriate Agent configurations.
Policy Configuration, Shared Components: Confirm that a new Host Identifier definition was created:
Policy Configuration, Application Domain:
Confirm that a new Application domain was created:
Within the new Application domain, confirm that Resources exist for
Within the new Application domain, confirm that an Authentication Policy exists with the appropriate Host Identifier:
Protected Resource Policy
Access the partner application and confirm that authentication occurs through Oracle Access Manager 11g (check the login form for 11g).
Proceed as follows:
Success: Continue with "Validating Post-Upgrade SSO with OSSO-Protected Resources".
No Success: Confirm that you have completed all steps as needed.
You can use the following steps to confirm that single sign-on is occurring after the upgrade in an environment that includes OSSO 10g-protected resources and Oracle Access Manager 11g-protected resources.
OAM-Protected Resources: Perform steps in "Validating Post-Upgrade SSO with Oracle Access Manager Protected Resources" to confirm that OAM 11g protected resources are being accessed through OAM 11g.
OSSO-Protected Resources: Perform the following steps to confirm that OSSO-protected resources are being accessed through OSSO 10g:
Stop the OAM Server.
Restart the Oracle HTTP Server on the computer that is hosting the 10g OSSO Server.
Access an OSSO-protected resource to confirm that the 10g OSSO server is authenticating (10g OSSO login page).
Restart the OAM Server.