8 Coexistence of Oracle Access Manager 10g with Oracle Access Management Access Manager 11.1.2.2.0

This chapter describes how to setup an environment where both Oracle Access Manager 10g and Oracle Access Management Access Manager (Access Manager) 11g Release 2 (11.1.2.2.0) deployments coexist.

This chapter contains the following sections:

8.1 Coexistence Overview

Both Oracle Access Manager 10g and Access Manager 11.1.2.2.0 deployments can coexist, so that some applications are protected by Oracle Access Manager 10g while others are protected by Access Manager 11.1.2.2.0. This is called Coexistence mode, where both Oracle Access Manager 10g and Access Manager 11.1.2.2.0 deployments coexist.

In the Coexistence mode, Access Manager 11.1.2.2.0 protects the migrated applications and any new applications registered with Access Manager 11.1.2.2.0; whereas Oracle Access Manager 10g continues to protect the applications that are not migrated to Access Manager 11.1.2.2.0.

End-users have a seamless single sign-on (SSO) experience when they navigate between applications that are protected by Oracle Access Manager 10g and applications protected by Access Manager 11.1.2.2.0.

8.2 Coexistence Features

Figure 8-1 illustrates how Oracle Access Manager 10g Server coexists with Access Manager 11.1.2.2.0 Server. Resource A is protected by Access Manager 11g WebGate and the other resources are protected by Oracle Access Manager 10g WebGates. You can configure Oracle Access Manager 10g WebGates to work with either Oracle Access Manager 10g server or Access Manager 11.1.2.2.0 server; Access Manager 11g WebGate can be configured to work with Access Manager 11.1.2.2.0 server only.

Figure 8-1 Coexistence of Oracle Access Manager 10g with Access Manager 11.1.2.2.0

Description of Figure 8-1 follows
Description of "Figure 8-1 Coexistence of Oracle Access Manager 10g with Access Manager 11.1.2.2.0"

  • Oracle Access Manager 10g and Access Manager 11.1.2.2.0 Servers can independently handle all authentication and authorization requests that are routed to them, without depending on each other.

  • All authentication schemes and policies are preserved during coexistence. This applies for both existing applications protected by Oracle Access Manager 10g and the migrated applications protected by the Access Manager 11.1.2.2.0 platform. For example, if an application is protected by X509 authentication scheme, then it is protected by X509 authentication scheme even in the Access Manager 11.1.2.2.0 platform, during coexistence.

  • Users authenticated by Access Manager 11.1.2.2.0 Server need not enter credentials again if they access any resource protected by Oracle Access Manager 10g server and vice versa. This provides users a seamless single sign-on (SSO) experience. A user can access resource B protected by Oracle Access Manager 10g and then access resource A protected by Access Manager 11.1.2.2.0 without entering the user credentials again.

  • Only one session is created per user, so you cannot use session management feature in Coexistence mode.

  • If a user logs out from any one of the servers, the session ends and the user is logged out from both Access Manager 11.1.2.2.0 and Oracle Access Manager 10g servers. A user can access any protected resource only after re-authentication.

  • Users can leverage all authentication related features and enhancements of Access Manager 11.1.2.2.0 in Coexistence mode. For more information about enhancements in Oracle Access Manager 11.1.2.2.0, see "Product Enhancements for Oracle Access Management 11.1.2.2.0" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

  • Authentication level for all protected resources must be the same, irrespective of the authentication scheme. In Figure 8-1, Resources A, B, and C must have the same authentication level, otherwise user will need to enter credentials again while trying to access resources having different authentication levels.

  • In Coexistence mode, no settings are required on the Access Manager 11g server to enable SSO across multiple data centers (MDC). The ObSSOCookie, which is generated by both Access Manager 11g server and Oracle Access Manager 10g server, is used as the source of user authorization. Plain 10g MDC mode is supported in Coexistence mode where cookie validation is the only criteria for a valid user session. If user session is not present in any data center, a new session is created irrespective of the existing session in other data center. For more information about deploying MDC, see "Using Multi-Data Centers" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

8.2.1 About Credential Collection

Access Manager 11.1.2.2.0 Server provides two mechanisms for collecting credentials during authentication processing:

  • Embedded Credential Collector (ECC). The default ECC is installed with the Access Manager Server and can be used as-is with no additional installation or set up steps. For more information about collecting and processing user credentials with ECC, see "About SSO Login Processing with OAM Agents and ECC" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

  • Separate Detached Credential Collector (DCC) and Resource WebGate. This is a distributed deployment where WebGates protecting applications are managed independently from the centralized DCC. The Resource WebGate which protects the resource redirects the user request to the DCC-enabled 11g WebGate for authentication. For more information about collecting and processing user credentials with DCC, see "About Login Processing with OAM Agents and DCC" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

Table 8-1 provides a comparison of the mechanisms used for collecting credentials in Coexistence Mode by WebGate 11g and WebGate 10g registered with Access Manager 11.1.2.2.0 Server.

Table 8-1 Comparison: WebGate 11g versus WebGate 10g with Access Manager 11g


 11g WebGate 10g WebGate

ECC

Does not support ECC for collecting credentials.

Supports ECC for collecting credentials.

DCC

Requires a DCC-enabled 11g WebGate, which is separate from an 11g Resource WebGate, to work in Coexistence Mode.

Requires ECC or a DCC-enabled 11g WebGate.

Table 8-2 provides a comparison of the mechanisms used for collecting credentials by WebGate 10g in 10g and 11g deployments. For more differences between installing a 10g Webgate to operate in an 11g Access Manager deployment versus installing the 10g Webgate in an 10g Oracle Access Manager deployment, see "Table 23-1 Installation Comparison with 10g Webgates" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

Table 8-2 Comparison: WebGate 10g in 11g Deployment versus 10g Deployment


 10g WebGate in 11g Deployment 10g WebGate in 10g Deployment

Login Form

You cannot use 10g forms provided with 10g WebGates with Access Manager Server.

Using 10g WebGates with Access Manager Server is similar in operation and scope to a resource WebGate (one that redirects in contrast to the Authentication WebGate). With a 10g WebGate and 11g OAM Server, the 10g WebGate always redirects to the 11g credential collector which acts like the Authenticating WebGate.

You can use the 10g forms which were provided for use in 10g deployments.

8.3 Coexistence Topology

Figure 8-1 illustrates how Oracle Access Manager 10g Server coexists with Access Manager 11.1.2.2.0 Server.

The topology consists of disjoint Oracle Access Manager 10g and Access Manager 11.1.2.2.0 setups where resources, WebGates, and servers are in the same domain.

This coexistence setup contains the following:

  • Oracle Access Manager 10g WebGate partners registered against Access Manager 11.1.2.2.0 Server. To enable coexistence, configure Oracle Access Manager 10g WebGate with DCC or ECC in 11g Access Manager.

  • Oracle Access Manager 10g WebGate partners registered against Oracle Access Manager 10g Server.

  • Access Manager 11g WebGate partners registered against Access Manager 11.1.2.2.0 Server.

Topology Description

  • WebGate 11g-1: This refers to the 11g WebGate partner registered with Access Manager 11.1.2.2.0 Server. It is deployed on Oracle HTTP Server 11g named OHS-1. WebGate 11g-1 protects Resource A, an application that is installed on Access Manager 11.1.2.2.0 Server. 11g WebGates work only with Access Manager 11.1.2.2.0 Server. To enable 11g WebGate to work in coexistence mode, you must configure the 11g WebGate to work with a detached credential collector (DCC).

  • WebGate 11g-2: This refers to the 11g WebGate configured as a detached credential collector (DCC). An 11g WebGate configured to act as a detached credential collector (DCC) is known as an Authenticating WebGate. The other 11g WebGate, WebGate 11g-1, which protects resources, is called Resource WebGate. WebGate 11g-1 and WebGate 11g-2 work together in coexistence mode as separate DCC and Resource WebGates.

    The Resource WebGate does not communicate directly with the Access Manager 11.1.2.2.0 Server. Access Manager 11.1.2.2.0 Server receives requests from the Resource WebGate and redirects authentication requests to the DCC. The DCC sets the ObSSOCookie for the session, which is honored by both the Access Manager 11.1.2.2.0 Server and Oracle Access Manager 10g Server. For information about configuring 11g WebGates as Separate DCC and Resource WebGates, see "Configuring 11g Webgate and Authentication Policy for DCC" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

  • WebGate 10g-1: This refers to the Oracle Access Manager 10g WebGate partner registered with Access Manager 11.1.2.2.0 Server. It is deployed on Oracle HTTP Server 11g named OHS-2. WebGate 10g-1 protects Resource C, an application that is installed on Access Manager 11.1.2.2.0 server.

  • WebGate 10g-2: This refers to the Oracle Access Manager 10g WebGate partner registered with Oracle Access Manager 10g Server. It is deployed on Oracle HTTP Server 11g named OHS-3. WebGate 10g-2 protects Resource B, an application that is protected by Oracle Access Manager 10g.

  • User Identity Store: Access Manager 11.1.2.2.0 Server and Oracle Access Manager 10g Server are configured to share the same user identity store, so that both the servers can validate and update the ObSSOCookie, which is present in the user request.

The following scenarios explain how SSO works in Coexistence mode when user accesses resources that are protected by Access Manager 11.1.2.2.0 Server and Oracle Access Manager 10g Server:

8.3.1 Accessing resource protected by 10g WebGate and Oracle Access Manager 10g and then accessing resource protected by 10g WebGate and Access Manager 11g

In the coexistence mode, if a user has already been authenticated by Oracle Access Manager 10g Server, the Access Manager 11.1.2.2.0 Server honors the ObSSOCookie set by Oracle Access Manager 10g Server and creates a unified session. Hence, the user does not need to enter credentials again.

Figure 8-2 illustrates how SSO works in the coexistence mode when a user accesses Resource B which is protected by WebGate 10g-2 registered against Oracle Access Manager 10g Server, and then accesses Resource C which is protected by WebGate 10g-1 registered against Access Manager 11.1.2.2.0 Server.

Figure 8-2 User accesses Resource B protected by 10g WebGate and Oracle Access Manager 10g and then tries to access Resource C protected by 10g WebGate and Access Manager 11g

Description of Figure 8-2 follows
Description of "Figure 8-2 User accesses Resource B protected by 10g WebGate and Oracle Access Manager 10g and then tries to access Resource C protected by 10g WebGate and Access Manager 11g"

Table 8-3 describes the request flow. The numbers in the Step column correspond to the numbers shown in the topology in Figure 8-2 and show the sequence in which the requests flow in the coexistence environment.

Table 8-3 Request Flow

Step Description

1

User requests access to Resource-B, which is protected by Oracle Access Manager 10g Server at the following URL:

http://OHS-3:port/ResourceB

where OHS-3 is the hostname of the Oracle HTTP Server 10g (OHS-3), and the port is the port number of the machine on which OHS-3 is running.

2

WebGate 10g-2 which is deployed on OHS-3 intercepts the request, and communicates with the Oracle Access Manager 10g Server to authenticate the user.

3

WebGate 10g-2 redirects the user to a login form to collect the credentials.

4 and 5

When the user provides the credentials, WebGate 10g-2 communicates with Oracle Access Manager 10g Server to perform authentication followed by authorization. After authorization, the Oracle Access Manager 10g server provides all relevant headers and ObSSOCookie to WebGate 10g-2 according to the policy configuration. WebGate 10g-2 sets the ObSSOCookie in the user's browser.

6

User requests access to Resource-C, which is protected by Access Manager 11.1.2.2.0 Server at the following URL:

http://OHS-2:port/ResourceC

where OHS-2 is the hostname of the Oracle HTTP Server 11g (OHS-2), and the port is the port number of the machine on which OHS-2 is running.

The request contains the ObSSOCookie set in the header by WebGate 10g-2.

7-8

Access Manager 11.1.2.2.0 server validates the ObSSOCookie, authorizes the user, creates a unified session, and sends the refreshed ObSSOCookie to WebGate 10g-1 according to the policy configuration.

8.3.2 Accessing resource protected by 11g WebGate and Access Manager 11g and then accessing resource protected by 10g WebGate and Oracle Access Manager 10g

Figure 8-3 illustrates how SSO works in the coexistence mode when a user accesses Resource A protected by Access Manager 11.1.2.2.0 Server, and then accesses Resource B protected by the Oracle Access Manager 10g Server.

Figure 8-3 User accesses Resource A protected by 11g WebGate and Access Manager 11g Server and then tries to access Resource C protected by 10g WebGate and Oracle Access Manager 10g Server

Description of Figure 8-3 follows
Description of "Figure 8-3 User accesses Resource A protected by 11g WebGate and Access Manager 11g Server and then tries to access Resource C protected by 10g WebGate and Oracle Access Manager 10g Server"

Table 8-4 describes the request flow. The numbers in the Step column correspond to the numbers shown in the topology in Figure 8-3 and show the sequence in which the requests flow in the coexistence environment.

Table 8-4 Request Flow

Step Description

1

User requests access to Resource-A, which is protected by Access Manager 11.1.2.2.0 Server at the following URL:

http://OHS-1:port/ResourceA

where OHS-1 is the hostname of the Oracle HTTP Server 11g (OHS-1), and the port is the port number of the machine on which OHS-1 is running.

2

WebGate 11g-1 which is deployed on OHS-1 intercepts the request and communicates with Access Manager 11.1.2.2.0 Server to obtain the authentication scheme.

3

Access Manager 11.1.2.2.0 Server redirects the request to the detached credential collector (DCC), which throws the login page. The DCC collects and processes the credentials entered by the user for authentication.

4-5

When user provides the credentials, the detached credential collector communicates with Access Manager 11.1.2.2.0 Server to perform authentication followed by authorization. After authorization, the Access Manager 11.1.2.2.0 server provides all relevant headers and ObSSOCookie to WebGate 11g-1 according to the policy configuration. ObSSOCookie is generated as per Oracle Access Manager 10g Server specifications, and WebGate 11g-1 sets the ObSSOCookie in the user's browser.

6

User requests access to Resource-B, which is protected by Oracle Access Manager 10g Server, at the following URL:

http://OHS-2:port/ResourceB

where OHS-2 is the hostname of the Oracle HTTP Server 10g (OHS-2), and the port is the port number of the machine on which OHS-2 is running.

The request contains the ObSSOCookie set in the header by WebGate 11g-1.

7-8

Oracle Access Manager 10g Server decrypts and validates the ObSSOCookie, authorizes the user, and sends the refreshed ObSSOCookie to WebGate10g-2 according to the policy configuration.

In the coexistence mode, Access Manager 11.1.2.2.0 Server redirects the user request to a credential collector to collect credentials for both 10g and 11g WebGates. For comparison of the mechanisms used for collecting credentials in Coexistence mode by WebGate 11g and WebGate 10g, see Section 8.2.1, "About Credential Collection".

8.3.3 Accessing resource protected by 10g WebGate and Access Manager 10g and then accessing resource protected by 11g WebGate and Access Manager 11g

Figure 8-4 illustrates how SSO works in the coexistence mode when a user accesses Resource B protected by Oracle Access Manager 10g Server, and then accesses Resource A protected by Access Manager 11.1.2.2.0 Server.

Figure 8-4 User accesses Resource B protected by 10g WebGate and Access Manager 10g Server and then tries to access Resource A protected by 11g WebGate and Access Manager 11g Server

Description of Figure 8-4 follows
Description of "Figure 8-4 User accesses Resource B protected by 10g WebGate and Access Manager 10g Server and then tries to access Resource A protected by 11g WebGate and Access Manager 11g Server"

Table 8-5 describes the request flow. The numbers in the Step column correspond to the numbers shown in the topology in Figure 8-4 and show the sequence in which the requests flow in the coexistence environment.

Table 8-5 Request Flow

Step Description

1

User requests access to Resource-B, which is protected by Oracle Access Manager 10g Server at the following URL:

http://OHS-3:port/ResourceB

where OHS-3 is the hostname of the Oracle HTTP Server 10g (OHS-3), and the port is the port number of the machine on which OHS-3 is running.

2

WebGate 10g-2 which is deployed on OHS-3 intercepts the request, and communicates with the Oracle Access Manager 10g Server to authenticate the user.

3

WebGate 10g-2 redirects the user to a login form to collect the credentials.

4 and 5

When the user provides the credentials, WebGate 10g-2 communicates with Oracle Access Manager 10g Server to perform authentication followed by authorization. After authorization, the Oracle Access Manager 10g server provides all relevant headers and ObSSOCookie to WebGate 10g-2 according to the policy configuration, and these are then set by the WebGate. WebGate 10g-2 sets the ObSSOCookie in the user's browser.

6

User requests access to Resource-A, which is protected by Access Manager 11.1.2.2.0 Server at the following URL:

http://OHS-1:port/ResourceA

where OHS-1 is the hostname of the Oracle HTTP Server 11g (OHS-2), and the port is the port number of the machine on which OHS-1 is running.

The request contains the ObSSOCookie set in the header by WebGate 10g-2.

7

WebGate 11g-1 which is deployed on OHS-1 intercepts the request, and communicates with Access Manager 11.1.2.2.0 Server to obtain the authentication scheme.

8

Access Manager 11.1.2.2.0 Server redirects the request to the DCC along with the ObSSOCookie set by WebGate 10g-2.

9-10

DCC communicates with Access Manager 11.1.2.2.0 Server to perform authentication followed by authorization. After authorization, the Access Manager 11.1.2.2.0 server sends the refreshed ObSSOCookie to WebGate 11g-1 according to the policy configuration.

8.3.4 Accessing resource protected by 10g WebGate and Access Manager 11g and then accessing resource protected by 11g WebGate and Access Manager 11g

Figure 8-5 illustrates how SSO works in the coexistence mode when a user accesses Resource C protected by Access Manager 11.1.2.2.0 Server, and then accesses Resource A protected by the Access Manager 11.1.2.2.0 Server.

Figure 8-5 User accesses Resource C protected by 10g WebGate and Access Manager 11g Server and then tries to access Resource A protected by 11g WebGate and Access Manager 11g Server

Description of Figure 8-5 follows
Description of "Figure 8-5 User accesses Resource C protected by 10g WebGate and Access Manager 11g Server and then tries to access Resource A protected by 11g WebGate and Access Manager 11g Server"

Table 8-6 describes the request flow. The numbers in the Step column correspond to the numbers shown in the topology in Figure 8-5 and show the sequence in which the requests flow in the coexistence environment.

Table 8-6 Request Flow

Step Description

1

User requests access to Resource-C, which is protected by Access Manager 11.1.2.2.0 Server at the following URL:

http://OHS-2:port/ResourceC

where OHS-2 is the hostname of the Oracle HTTP Server 10g (OHS-2), and the port is the port number of the machine on which OHS-2 is running.

2

WebGate 10g-1 which is deployed on OHS-2 intercepts the request, and communicates with Access Manager 11.1.2.2.0 Server to obtain the authentication scheme.

3

Access Manager 11.1.2.2.0 Server redirects the request to the ECC or DCC, which throws the login page. The ECC or DCC collects and processes the credentials entered by the user for authentication.

4-5

When user provides the credentials, the ECC or DCC communicates with Access Manager 11.1.2.2.0 Server to perform authentication followed by authorization. After authorization, the Access Manager 11.1.2.2.0 server provides all relevant headers and ObSSOCookie to WebGate 10g-1 according to the policy configuration. WebGate 10g-1 sets the ObSSOCookie in the user's browser.

6

User requests access to Resource-A, which is protected by Access Manager 11.1.2.2.0 Server at the following URL:

http://OHS-1:port/ResourceA

where OHS-1 is the hostname of the Oracle HTTP Server 11g (OHS-1), and the port is the port number of the ma

chine on which OHS-1 is running.

The request contains the ObSSOCookie set in the header by WebGate 10g-1.

7

WebGate 11g-1 which is deployed on OHS-1 intercepts the request, and communicates with Access Manager 11.1.2.2.0 Server to obtain the authentication scheme.

8

Access Manager 11.1.2.2.0 Server redirects the request to the DCC along with the ObSSOCookie set by WebGate 10g-1.

9

DCC communicates with Access Manager 11.1.2.2.0 Server to perform authentication followed by authorization. After authorization, the Access Manager 11.1.2.2.0 server sends the refreshed ObSSOCookie to WebGate 11g-1 according to the policy configuration.

8.4 Task Roadmap

Table 8-7 lists the steps to set up and configure the topology shown in Figure 8-1.

Table 8-7 Tasks to be Completed

Task No Task For More Information

1

Understand and get familiar with the coexistence topology before you start the configuration process.

See Coexistence Topology

2

Complete the prerequisites.

See Prerequisites for Coexistence

3

Install a new Oracle HTTP Server 11g instance (OHS-1).

If you do not want to install a new Oracle HTTP Server instance, you can use the Oracle HTTP Server instance which is available as part of your Oracle Access Manager 10g migration.

See Optional: Installing and Configuring Oracle HTTP Server 11g (OHS-1)

4

Install a new 11g WebGate and configure it to work with Access Manager 11.1.2.2.0 Server and DCC.

WebGate 11g-1 is deployed on OHS-1 and configured with Access Manager 11.1.2.2.0 Server.

See Optional: Installing and Configuring WebGate 11g-1

5

Use the existing 10g Webgares or install three WebGates: WebGate 10g-1 and WebGate 10g-2. You can install 10g or 11g WebGates. You can configure 10g WebGates to work with Access Manager 11.1.2.2.0 Server or Oracle Access Manager 10g Server. You can configure 11g WebGates to work only with Access Manager 11.1.2.2.0 Server.

WebGate 10g-1 is deployed on OHS-2 and configured with Access Manager 11.1.2.2.0 Server.

WebGate 10g-2 is deployed on OHS-3 and configured with Oracle Access Manager 10g Server. This WebGate must be a 10g WebGate.

See Optional: Installing and Configuring 10g WebGates

6

Enable coexistence mode on the Access Manager 11.1.2.2.0 Server

See Enabling Coexistence Mode on Access Manager 11.1.2.2.0 Server

7

Configure the logout settings to ensure that the logout works at both the WebGates and the Access Manager 11.1.2.2.0 server.

See Configuring Logout Settings

8

Verify the configuration.

See Verifying the Configuration

8.5 Prerequisites for Coexistence

You must complete the following prerequisites before you start performing tasks required for coexistence of Oracle Access Manager 10g Server with Access Manager 11.1.2.2.0 Server.

  1. Read the system requirements and certification documents to ensure that your environment meets the minimum requirements for the products you are installing.

    • Oracle Fusion Middleware System Requirements and Specifications

      This document contains information related to hardware and software requirements, minimum disk space and memory requirements, and required system libraries, packages, or patches.

    • Oracle Fusion Middleware Supported System Configurations

      This document contains information related to supported installation types, platforms, operating systems, databases, JDKs, and third-party products.

    • For interoperability and compatibility issues that may arise when installing, refer to Oracle Fusion Middleware Interoperability and Compatibility Guide.

      This document contains important information regarding the ability of Oracle Fusion Middleware products to function with previous versions of other Oracle Fusion Middleware, Oracle, or third-party products. This information is applicable to both new Oracle Fusion Middleware users and existing users who are upgrading their existing environment.

    Note:

    For information about Oracle Fusion Middleware concepts and directory structure, see "Understanding Oracle Fusion Middleware Concepts and Directory Structure" in the Oracle Fusion Middleware Installation Planning Guide for Oracle Identity and Access Management.

  2. Verify that the version of Oracle Access Manager 10g that you are using is supports coexistence. For more information about supported starting points for coexistence of Oracle Access Manager 10g with Access Manager 11.1.2.2.0, see Section 1.4, "Supported Starting Points for Migration and Coexistence".

  3. Ensure that the Oracle Access Manager 10g and the Access Manager 11.1.2.2.0 servers are up and running.

  4. Configure user identity store in Access Manager 11.1.2.2.0. For more information about configuring user identity store, see Section 8.5.1, "Configuring User Identity Store in Access Manager 11.1.2.2.0".

  5. Install JDK 6 or JDK 7 on all the Access Manager 11.1.2.2.0 servers that you want to run in coexistence mode with Oracle Access Manager 10g servers.

  6. Download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 7 from the Oracle Technology Network website at http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html and place the US_export_policy.jar and local_policy.jar files in the jre/lib/security folder.

8.5.1 Configuring User Identity Store in Access Manager 11.1.2.2.0

While configuring the User Identity Store in Access Manager 11.1.2.2.0, you need to complete the following tasks:

  • Set Access Manager 11.1.2.2.0 Server as a default store.

  • Ensure that Oracle Access Manager 10g and Access Manager 11.1.2.2.0 servers share the same user store.

  • Mark the shared data store as the default data store.

  • Select the shared data store under LDAP Authentication Module.

To do this, complete the following steps:

  1. Log in to the Oracle Access Management 11.1.2.2.0 console using the following URL:

    http://host:port/oamconsole

    In this URL,

    • host refers to fully qualified domain name of the machine hosting the Oracle Access Manager console (Administration Server).

    • port refers to the designated bind port for the Oracle Access Management 11.1.2.2.0 console, which is the same as the bind port for the Administration Server.

  2. Under Configuration, click User Identity Stores.

  3. Create a User Identity Store, whose location or host information points to the Access Manager 11.1.2.2.0 server. For more information about creating a user identity store, see "Registering a New User Identity Store" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

  4. On the User Identity Stores page, under Default and System store, select the user identity store you have created.

  5. Click Apply.

  6. On the Oracle Access Management Launch Pad, under Access Manager, click Authentication Modules. A list of authentication modules appears.

  7. Click LDAP and update the User Identity Store to point to the user identity store that you have just created.

  8. Click Apply.

8.6 Optional: Installing and Configuring Oracle HTTP Server 11g (OHS-1)

Install and configure Oracle HTTP Server 11g (OHS-1 as shown in Figure 8-1). Alternatively, you can use the Oracle HTTP Server instances that exist after migration from Oracle Access Manager 10g to Access Manager 11.1.2.2.0.

For more information, see "Installing and Configuring Oracle HTTP Server 11g" in the Oracle Fusion Middleware Installing WebGates for Oracle Access Manager.

You can install 11g WebGate on the following web servers: Oracle HTTP Server (OHS), Oracle Traffic Director, and Apache 2. In the sample topology which we consider in this chapter, all WebGates are considered to be installed on OHS.

8.7 Optional: Installing and Configuring WebGate 11g-1

To enable 11g WebGates to work in coexistence mode, you must configure the 11g Resource WebGate to work with a DCC-enabled 11g WebGate as Separate DCC and Resource WebGates.

  • Install and configure an 11g WebGate, which protects resources, to work with the DCC. This WebGate is called the Resource WebGate. Access Manager 11.1.2.2.0 server redirects the authentication requests it receives from the Resource WebGate to the DCC to collect and process authentication. Install a new 11g WebGate instance on Oracle HTTP Server 11g (OHS-1), as shown in Figure 8-1, and configure it with the Access Manager 11.1.2.2.0 Server. For information about installing 11g WebGate and configuring it with the Access Manager 11.1.2.2.0 server, see "Installing and Configuring Oracle HTTP Server 11g WebGate for OAM" in the Oracle Fusion Middleware Installing WebGates for Oracle Access Manager.

  • Install and configure an 11g WebGate to act as a detached credential collector (DCC). This WebGate is also known as an Authenticating WebGate. For information about configuring 11g WebGates as Separate DCC and Resource WebGate, see "Configuring 11g WebGate and Authentication Policy for DCC" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

Note:

The DCC must be in the same domain as the Authenticating WebGate of Oracle Access Manager 10g Server, so that the ObSSOCookie can be passed to both WebGates.

8.8 Optional: Installing and Configuring 10g WebGates

You can either use existing 10g WebGate instances for setting up the coexistence environment or install new 10g WebGate instances.

If you want to install new WebGates instances: WebGates 10g-1 and WebGates 10g-2, you must configure them as follows:

  • WebGate 10g-1: Install a 10g WebGate on Oracle HTTP Server 11g (OHS-2), as shown in Figure 8-1, and configure it with the Access Manager 11.1.2.2.0 Server.

    For information about installing 10g WebGate, and configuring it with the Access Manager 11.1.2.2.0 server, see "Locating and Installing the Latest 10g WebGate for Oracle Access Manager 11g" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

    When you use a 10g WebGate with Access Manager 11.1.2.2.0 Server, the 10g WebGate behaves as a Resource WebGate and always redirects to the 11g credential collector which acts as the Authenticating WebGate. You can configure 10g WebGates to work with the default Embedded Credential Collector (ECC) that is installed with the Access Manager 11.1.2.2.0 Server or a 11g WebGate configured as a Detached Credential Collector (DCC). For more information about ECC and DCC, see "Introduction to Access Manager Credential Collection and Login" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

  • WebGate 10g-2: Install a 10g WebGate on Oracle HTTP Server 11g (OHS-2), as shown in Figure 8-1, and configure it with the Oracle Access Manager 10g Server.

    For information about installing 10g WebGate and configuring it with the Oracle Access Manager 10g Server, see "Installing the WebGate" in the Oracle Access Manager Installation Guide for release 10g (10.1.4.3).

For more information about managing 10g WebGates with Access Manager 11.1.2.2.0, see "Managing 10g WebGates with Oracle Access Manager 11g" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

Note:

All 10g WebGates configured with Oracle Access Manager 10g Server or Access Manager 11.1.2.2.0 Server should have the same primary cookie domain otherwise ObSSOCookie cannot be passed from one WebGate to another.

8.9 Enabling Coexistence Mode on Access Manager 11.1.2.2.0 Server

Run the following WebLogic Scripting Tool commands to configure each instance of Access Manager 11.1.2.2.0 server to run in coexistence mode with the Oracle Access Manager 10g server.

  1. Run the following command from the location IAM_HOME/common/bin to launch the WebLogic Scripting Tool (WLST):

    On UNIX:

    ./wlst.sh

    On Windows:

    wlst.cmd

  2. Run the following command to connect WLST to the WebLogic Server instance:

    connect('wls_admin_username','wls_admin_password','t3://hostname:port');

    In this command,

    wls_admin_username is the username of the WebLogic Administration Server.

    wls_admin_password is the password of the WebLogic Administration Server.

    hostname is the machine where WebLogic Administration Server is running.

    port is the port of the Administration Server.

  3. Run the following command to provide information about the user identity store of Oracle Access Manager 10g server and set the ObSSOCookie domain:

    setCoexistenceConfigWith10G(ldapUrl="ldap://<hostname>:<port>/" , ldapPrinciple="cn=oamadmin" , ldapConfigBase="dc=com,dc=oracle,dc=us" , coexCookieDomain="");

    In this command,

    ldapUrl is the LDAP host and the port of the configuration store used in Oracle Access Manager 10g deployment.

    ldapPrinciple is the LDAP DN of the administrator for the configuration store.

    ldapConfigBase is the LDAP search base for the configuration store of the Oracle Access Manager 10g deployment.

    coexCookieDomain is the Web Server or WebGate domain of 10g Authenticating WebGate. It is important to know the authenticating domain of the 10g WebGate as the ObSSOCookie set by the DCC must flow to the Oracle Access Manager 10g server.

    For Example: setLdapConfigForCoexistenceWith10G(ldapUrl="ldap://<hostname>:<port>" , ldapPrinciple="cn=oamadmin", ldapPolicybase="dc=com,dc=oracle,dc=us", coexCookieDomain="")

    You are prompted to enter the LDAP administrator's password.

  4. Enter the LDAP administrator's password.

  5. Run the following command to enable the Access Manager 11.1.2.2.0 server to run in coexistence mode with Oracle Access Manager 10g.

    enableOamAgentCoexistWith10G()

  6. Restart Access Manager 11.1.2.2.0 server.

  7. Repeat these steps to configure each instance of Access Manager 11.1.2.2.0 Server to run in coexistence mode with Oracle Access Manager 10g Servers.

8.10 Configuring Logout Settings

WebGate 10g uses the logout.html file to clear the session. Modify the logout.html file, which is generated when you register WebGate 10g-1 with the Access Manager 11.1.2.2.0 Server, to update SERVER_LOGOUTURL parameter in the file to point to the Access Manager 11.1.2.2.0 Server's logout URL. The Access Manager 11.1.2.2.0 Server, configured in coexistence mode, removes both the cookies (OAMAuthnCookie and ObSSOCookie) from the request header.

Perform the following steps to modify the logout.html file which is generated when you register WebGate 10g-1 with the Access Manager 11.1.2.2.0 Server.

  1. Set the variable SERVER_LOGOUTURL in the logout.html file to the logout URL, which points to the host and port of OHS-2 as shown in the following example:

    var SERVER_LOGOUTURL="http://OHS-2_host:OHS-2_port/oam/server/logout"

    In this URL,

    OHS-2_host is the host on which OHS-2 is running.

    OHS-2_port is the port of OHS-2.

  2. Optional: If you wish to allow users to access the logout URL, configure a policy in Oracle Access Manager 10g. For information about creating an Oracle Access Manager 10g policy, see "Protecting Resources with Policy Domains" in the Oracle Access Manager Access Administration Guide for release 10g (10.1.4.3).

After modifying the logout.html file, ensure that logout works at both the WebGates and the Access Manager 11.1.2.2.0 Server. To do this, complete the following steps:

  • Use the following URL to initiate and verify logout from the resource WebGate (WebGate 10g-1):

    http://OHS-2_host:OHS-2_port/logout.html

    In this URL,

    OHS-2_host is the host on which OHS-2 is running.

    OHS-2_port is the port of OHS-2.

    WebGate 10g-1 redirects to the Access Manager 11.1.2.2.0 Server's logout URL. Therefore, WebGate 10g-1 forwards the request to the Access Manager 11.1.2.2.0 server. The Access Manager 11.1.2.2.0 server clears all the sessions.

8.11 Verifying the Configuration

You must verify the configuration by doing the following:

  1. Login to access the resource protected by WebGate 10g-1.

  2. Try to access the resource protected by WebGate 10g-2 or WebGate 11g-1. If you have successfully configured the servers to work in coexistence mode, you should be able to access the resources protected by these WebGates without entering the user credentials again.

  3. Initiate logout and verify whether you are logged out from all the WebGates by accessing a resource. To access any resource, you should be prompted to enter your user credentials again.

8.12 Disabling Coexistence Feature

After migrating all the artifacts of Oracle Access Manager 10g server to Access Manager 11.1.2.2.0 server, you can decommission the Oracle Access Manager 10g server and stop running the Access Manager 11.1.2.2.0 server in coexistence mode. For information about migrating Oracle Access Manager 10g artifacts, see Chapter 2, "Migrating Oracle Access Manager 10g Environments".

  1. Run the following command from the location IAM_HOME/common/bin to launch the WebLogic Scripting Tool (WLST):

    On UNIX:

    ./wlst.sh

    On Windows:

    wlst.cmd

  2. Run the following WLST command on the Access Manager 11.1.2.2.0 server to stop running the Access Manager 11.1.2.2.0 server in coexistence mode with Oracle Access Manager 10g.

    disableOamAgentCoexistWith10G()

  3. Restart the Access Manager 11.1.2.2.0 server.

8.13 Known Issue

Oracle Access Manager 10g servers that have a 64 bit AES key do not support Coexistence mode

In Coexistence mode, the Access Manager 11.1.2.2.0 server requires a 128-, 192-, or 256-bit AES key, which is supported by JVM. When you install Oracle Access Manager 10g server, a 256-bit AES key for encryption is generated by default. If you regenerate this key in the Access System Console, a 64-bit key is generated. As JVM does not support 64 bit AES key, Access Manager 11.1.2.2.0 server cannot work in coexistence mode with Oracle Access Manager 10g servers that have a 64 bit AES key.

The workaround for this issue is to delete the AES key from LDAP, and then regenerate a 256-bit key in Oracle Access Manager 10g Server.

To delete the AES key, complete the following steps:

  1. Open the configuration LDAP of Oracle Access Manager 10g Server in the LDAP browser.

  2. Navigate to Oblix > encryptionKey > cookieEncryptionKey node.

  3. Right-click cookieEncryptionKey node, and then click Delete. The key is deleted.

To regenerate a 256-bit key in Oracle Access Manager 10g Server:

  1. Restart the Oracle Access Manager 10g Server and identity server.

  2. Click on any link on the following URL:

    http://host:port/identity/oblix

    The key is generated. You can see the generated key in the LDAP browser.

  3. Restart Access Manager 11.1.2.2.0 server to configure the coexistence mode.