A Co-existence Overview: OAM 11g and OSSO 10g

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:

A.1 Prerequisites

See Oracle Fusion Middleware Upgrade Guide for Oracle Identity Management for upgrade steps.

A.2 Introduction to Upgrading and Co-existence with OracleAS 10g SSO

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.

Note:

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.

Note:

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".

A.3 Pre- and Post-Upgrade Topology and Authentication Examples

This section provides the following topics:

A.3.1 About Pre-Upgrade OSSO 10g Topology

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-1 Pre-Upgrade OSSO 10g Topology

Pre-Upgrade OSSO 10g Topology
Description of "Figure A-1 Pre-Upgrade OSSO 10g Topology "

A.3.1.1 Simple OSSO 10g with mod_oc4j on a Front-End Proxy Server

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.

Figure A-2 Pre-Upgrade Sample OSSO 10g with Front-End Proxy

OSSO 10g Sample Environment
Description of "Figure A-2 Pre-Upgrade Sample OSSO 10g with Front-End Proxy"

After upgrading the environment is configured to use Oracle Access Manager 11g for authentication.

A.3.2 About Post-Upgrade Topology and Co-existence

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).

Note:

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.

Figure A-3 Post-Upgrade OSSO 10g Topology

Post-Upgrade OSSO 10g Topology
Description of "Figure A-3 Post-Upgrade OSSO 10g Topology "

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.

Note:

With OSSO 10g, the server sets a host cookie that contains information about the logged in user.

For additional information, see:

A.3.2.1 Post-Upgrade: mod_wl Replaces mod_oc4j on the Proxy Server

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.

Figure A-4 mod_wl Replaces mod_oc4j on the Proxy Server

mod_wl Replaces mod_oc4j on the Proxy Server
Description of "Figure A-4 mod_wl Replaces mod_oc4j on the Proxy Server"

A.3.2.2 Post-Upgrade: No Proxy Server

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.

Figure A-5 Typical Topology Without Proxy Server

Typical Topology Without Proxy Server
Description of "Figure A-5 Typical Topology Without Proxy Server"

A.4 Introduction to Validating Post-Upgrade Co-Existence with OAM 11g

This section provides the following topics:

A.4.1 About Post-Upgrade SSO

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.

Figure A-6 Co-existence Processing

Co-existence Processing
Description of "Figure A-6 Co-existence Processing"

Process overview: Single Sign On between partner applications

  1. 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.

  2. 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.

  3. 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.

A.4.2 About Post-Upgrade OSSO 10g Authentication

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.

Figure A-7 Co-existence and OSSO 10g Authentication

Co-existence and OSSO 10g
Description of "Figure A-7 Co-existence and OSSO 10g Authentication"

Process overview: Post-upgrade OSSO 10g Authentication

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. The OAM 11g server must make sure that the session information in both the OSSO and OAM cookies are in sync.

A.5 Validating Post-Upgrade Co-existence

This section provides the following topics:

A.5.1 Validating Post-Upgrade Registration and Policies

The following topics provide information that help you locate transferred OSSO 10g details in the Oracle Access Manager Console:

A.5.1.1 Sample Partner Applications Protected Using OSSO 10g

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.

Table A-1 Partner Applications Protected by OSSO 10g

Application Name Host Oracle Home

oid1_ad2003_lowenthal.vm

ad2003.lowenthal.vm

C:\oracle\oid

portal1_ad2003_lowenthal.vm

ad2003.lowenthal.vm

C:\oracle\portal

Oracle Portal (portal)

ad2003.lowenthal.vm

C:\oracle\portal


OSSO 10g configuration details for each application includes administrator-assigned:

  • Name

  • Home Page URL

  • Success URL

  • Logout 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

  • Login URL

  • Single Log-Out URL

A.5.1.2 Policy Enforcement Agent Details

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.

  • Login URL

  • Single Log-Out URL

  • Success URL

  • Failure URL

  • Start Date

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-8 OSSO Agent Configuration Named for One Application

OSSO Agent Configuration Named for One Application
Description of "Figure A-8 OSSO Agent Configuration Named for One Application "

Figure A-9 shows the transferred configuration for a second application protected by OracleAS 10g SSO (OSSO).

Figure A-9 OSSO Agent Configuration Named for the Second Application

OSSO Agent Configuration Named for a Second Application
Description of "Figure A-9 OSSO Agent Configuration Named for the Second Application"

Figure A-10 shows the transferred OSSO Agent configuration for the third application protected with OracleAS 10g SSO (OSSO).

Figure A-10 OSSO Agent Configuration Named for the Third Application

OSSO Agent Configuration Named for the Third Application
Description of "Figure A-10 OSSO Agent Configuration Named for the Third Application"

A.5.1.3 Shared Components: Host Identifiers for migratedSSOPartners

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-11 Host Identifier for migratedSSOPartners

Host Identifier for migratedSSOPartners
Description of "Figure A-11 Host Identifier for migratedSSOPartners"

A.5.1.4 Resources in the migratedSSOPartners Application Domain

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 migratedSSOPartners.

Figure A-12 Resources in the migratedSSOPartners Application Domain

Resources in migratedSSOPartners Domain
Description of "Figure A-12 Resources in the migratedSSOPartners Application Domain "

A.5.1.5 Authentication Policy in the migratedSSOPartners Application Domain

Figure A-13 illustrates the Authentication Policy, named Protected Resource Policy, for the Application Domain migratedSSOPartners.

The default OAM 11g authentication scheme is used: LDAPScheme.

Figure A-13 Authentication Policy for the Application Domain migratedSSOPartners

Authentication Policy in migratedSSOPartners Domain
Description of "Figure A-13 Authentication Policy for the Application Domain migratedSSOPartners"

A.5.2 Validating Post-Upgrade SSO with Oracle Access Manager Protected Resources

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.

To confirm SSO is operational with Oracle Access Manager 11g

  1. Stop the Oracle HTTP Server on the computer that is hosting the 10g OSSO server.

  2. Restart the 11g OAM Server.

  3. 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: migratedssopartners.

    • Policy Configuration, Application Domain:

      • Confirm that a new Application domain was created: migratedssopartners

      • Within the new Application domain, confirm that Resources exist for migratedssopartners

      • Within the new Application domain, confirm that an Authentication Policy exists with the appropriate Host Identifier: Protected Resource Policy

  4. Access the partner application and confirm that authentication occurs through Oracle Access Manager 11g (check the login form for 11g).

  5. Proceed as follows:

A.5.3 Validating Post-Upgrade SSO with OSSO-Protected Resources

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.

To confirm post-upgrade SSO with OSSO-protected resources

  1. 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.

  2. OSSO-Protected Resources: Perform the following steps to confirm that OSSO-protected resources are being accessed through OSSO 10g:

    1. Stop the OAM Server.

    2. Restart the Oracle HTTP Server on the computer that is hosting the 10g OSSO Server.

    3. Access an OSSO-protected resource to confirm that the 10g OSSO server is authenticating (10g OSSO login page).

  3. Restart the OAM Server.