9 Coexistence of Oracle Access Manager 10g with Oracle Access Management Access Manager 11.1.2.3.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.3.0) deployments coexist.

This chapter contains the following sections:

9.1 Coexistence Overview

Both Oracle Access Manager 10g and Access Manager 11.1.2.3.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.3.0. This is called Coexistence mode, where both Oracle Access Manager 10g and Access Manager 11.1.2.3.0 deployments coexist.

In the Coexistence mode, Access Manager 11.1.2.3.0 protects the migrated applications and any new applications registered with Access Manager 11.1.2.3.0; whereas Oracle Access Manager 10g continues to protect the applications that are not migrated to Access Manager 11.1.2.3.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.3.0.

9.2 Coexistence Features

Figure 9-1 illustrates how Oracle Access Manager 10g Server coexists with Access Manager 11.1.2.3.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.3.0 server; Access Manager 11g WebGate can be configured to work with Access Manager 11.1.2.3.0 server only.

Figure 9-1 Coexistence of Oracle Access Manager 10g with Access Manager 11.1.2.3.0

Description of Figure 9-1 follows
Description of "Figure 9-1 Coexistence of Oracle Access Manager 10g with Access Manager 11.1.2.3.0"

  • Oracle Access Manager 10g and Access Manager 11.1.2.3.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.3.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.3.0 platform, during coexistence.

  • Users authenticated by Access Manager 11.1.2.3.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.3.0 without entering the user credentials again.

  • 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.3.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.3.0 in Coexistence mode. For more information about enhancements in Oracle Access Manager 11.1.2.3.0, see "Product Enhancements for Oracle Access Management 11.1.2.3.0" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

  • With coexistence and multiple data centers (MDC) enabled in Oracle Access Manager server configuration, the SessionDataRetrivalOnDemand flag must be set to false. The session will always be created in the Oracle Access Manager server if valid cookie is provided in the request. 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 "Understanding Multi-Data Centers" in Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

9.3 Supported Credential Collection Mechanisms

The Access Manager 11.1.2.3.0 Server supports the following credential collection mechanisms:

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

  • DCC Tunneling and Resource Webgate: This is a distributed deployment where WebGates protecting applications are managed independently from the centralized DCC configured as a Tunnel.

    For more information DCC tunneling, see "Tunneling from DCC to Access Manager Over Oracle Access Protocol" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

Table 9-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.3.0 Server.

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


 11g WebGate 10g WebGate

ECC

Supports 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 9-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 9-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.

9.4 Coexistence Topology

Figure 9-1 illustrates how Oracle Access Manager 10g Server coexists with Access Manager 11.1.2.3.0 Server.

The topology consists of disjoint Oracle Access Manager 10g and Access Manager 11.1.2.3.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.3.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.3.0 Server.

Topology Description

  • WebGate 11g-1: This refers to the 11g WebGate partner registered with Access Manager 11.1.2.3.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.3.0 Server. 11g WebGates work only with Access Manager 11.1.2.3.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.3.0 Server. Access Manager 11.1.2.3.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.3.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.3.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.3.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.3.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.3.0 Server and Oracle Access Manager 10g Server:

9.4.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.3.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 9-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.3.0 Server.

Figure 9-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 9-2 follows
Description of "Figure 9-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 9-3 describes the request flow. The numbers in the Step column correspond to the numbers shown in the topology in Figure 9-2 and show the sequence in which the requests flow in the coexistence environment.

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

9.4.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 9-3 illustrates how SSO works in the coexistence mode when a user accesses Resource A protected by Access Manager 11.1.2.3.0 Server, and then accesses Resource B protected by the Oracle Access Manager 10g Server.

Figure 9-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 9-3 follows
Description of "Figure 9-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 9-4 describes the request flow. The numbers in the Step column correspond to the numbers shown in the topology in Figure 9-3 and show the sequence in which the requests flow in the coexistence environment.

Table 9-4 Request Flow

Step Description

1

User requests access to Resource-A, which is protected by Access Manager 11.1.2.3.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.3.0 Server to obtain the authentication scheme.

3

Access Manager 11.1.2.3.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.3.0 Server to perform authentication followed by authorization. After authorization, the Access Manager 11.1.2.3.0 server provides all relevant headers and ObSSOCookie to WebGate 11g-2 according to the policy configuration. ObSSOCookie is generated as per Oracle Access Manager 10g Server specifications, and WebGate 11g-2 sets the ObSSOCookie in the user's browser and redirects to WebGate 11g-1 with OAMAuthnCookie.

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

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.3.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 9.3, "Supported Credential Collection Mechanisms".

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

Figure 9-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.3.0 Server.

Figure 9-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 9-4 follows
Description of "Figure 9-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 9-5 describes the request flow. The numbers in the Step column correspond to the numbers shown in the topology in Figure 9-4 and show the sequence in which the requests flow in the coexistence environment.

Table 9-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.3.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.3.0 Server to obtain the authentication scheme.

8

Access Manager 11.1.2.3.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.3.0 Server to perform authentication followed by authorization. After authorization, the Access Manager 11.1.2.3.0 server sends the refreshed ObSSOCookie to WebGate 11g-2 according to the policy configuration.

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

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

Figure 9-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 9-5 follows
Description of "Figure 9-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 9-6 describes the request flow. The numbers in the Step column correspond to the numbers shown in the topology in Figure 9-5 and show the sequence in which the requests flow in the coexistence environment.

Table 9-6 Request Flow

Step Description

1

User requests access to Resource-C, which is protected by Access Manager 11.1.2.3.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.3.0 Server to obtain the authentication scheme.

3

Access Manager 11.1.2.3.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.3.0 Server to perform authentication followed by authorization. After authorization, the Access Manager 11.1.2.3.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.3.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.3.0 Server to obtain the authentication scheme.

8

Access Manager 11.1.2.3.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.3.0 Server to perform authentication followed by authorization. After authorization, the Access Manager 11.1.2.3.0 server sends the refreshed ObSSOCookie to WebGate 11g-2 according to the policy configuration.

9.5 Limitations of Coexistence

The following are the limitations of server coexistence:

  • Since Server co-existence works on the basis of 10g ObSSOCookie, certain 11g server side session capabilities do not apply. Only a single unified session is created in 11g.

  • Maximum session limit for a user cannot be imposed, and administrators cannot purge a user's sessions. As long as user has a valid ObSSOCookie, the user will be able to stay authenticated.

  • Authentication level and Idle time out for a session are driven by values in the ObSSOCookie, not the 11g server.

  • Multi-data center (MDC) deployments are supported while on co-existence, but session data cannot be retrieved from one data center to the other.

  • Following session management features are not supported with coexistence enabled:

    • Application Domain Level Timeout: In Oracle Access Management 11g, the application domain level timeout is supported, which is maintained within the session. In coexistence, there is only one session per user login for all applications. Therefore, application domain timeouts are overridden in unified session.

    • Since there is only one session all time per login, the maximum number of session per login will always remain one.

    • Delete All User button: Delete All User button will delete all the user sessions. However, if Obssocookie is valid, then the session will be recreated. Only after the user logs out from the browser, the Obssocookie cookie will be deleted and the current session will be cleared.

    • Session is created if valid Obssocookie is found in the request. The Oracle Access Management 11g session in coexistence mode is entirely dependent on the validity of the Obssocookie. Hence, for all 10g WebGates and DCC WebGates, the idle session timeout and cookie session timeout should remain same across Oracle Access Manager 10g Server and Oracle Access Manager 11g Server.

9.6 Task Roadmap

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

Table 9-7 Tasks to be Completed

Task No Task For More Information

1

Understand and get familiar with the coexistence features, supported credential collector mechanisms, coexistence topology, and limitations of coexistence before you start the configuration process.

See the following sections:

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.3.0 Server and DCC or ECC.

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

See Optional: Installing and Configuring WebGate 11g-1

5

Use the existing 10g Webgates 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.3.0 Server or Oracle Access Manager 10g Server. You can configure 11g WebGates to work only with Access Manager 11.1.2.3.0 Server.

WebGate 10g-1 is deployed on OHS-2 and configured with Access Manager 11.1.2.3.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.3.0 Server

See Enabling Coexistence Mode on Access Manager 11.1.2.3.0 Server

7

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

See Configuring Logout Settings

8

Perform additional step to protect a mix of SSL and non-SSL applications.

See, Protecting a Mix of SSL and Non-SSL Applications in Coexistence

9

Verify the configuration.

See Verifying the Configuration

9.7 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.3.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.3.0, see Section 1.4, "Supported Starting Points for Migration and Coexistence".

  3. Ensure that the authentication level for all protected resources are same, irrespective of the authentication scheme. For example, in Figure 9-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.

  4. Ensure that the Oracle Access Manager 10g and the Access Manager 11.1.2.3.0 servers are up and running.

  5. Configure user identity store in Access Manager 11.1.2.3.0. For more information about configuring user identity store, see Section 9.7.1, "Configuring User Identity Store in Access Manager 11.1.2.3.0".

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

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

9.7.1 Configuring User Identity Store in Access Manager 11.1.2.3.0

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

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

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

  • Create an Authentication Module, and an Authentication Scheme corresponding to the Authentication Module.

To do this, complete the following steps:

  1. Log in to the Oracle Access Management 11.1.2.3.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.3.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.3.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 Store, select the user identity store you have created. It is recommended that OAM10g User Store is set as the default store in Access Manager 11g.

  5. Click Apply.

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

  7. Create a new LDAP Authentication Module, and update the user identity store to point to the one that you created in the previous steps.

  8. Create a new Authentication Scheme corresponding to the Authentication Module.

    For information about creating an Authentication Scheme, see "Creating an Authentication Scheme" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

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

Install and configure Oracle HTTP Server 11g (OHS-1 as shown in Figure 9-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.3.0.

For information about installing Oracle HTTP Server, see Oracle Fusion Middleware Installation Guide for Oracle Web Tier for 11g Release 1 (11.1.1.9.0)

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.

9.9 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.3.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 9-1, and configure it with the Access Manager 11.1.2.3.0 Server. For information about installing 11g WebGate and configuring it with the Access Manager 11.1.2.3.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.

  • Token Validity Period of 11g WebGate configured with DCC should be set to a value less than Idle Session Timeout of 10g AWG. This enables the DCC to refresh the ObSSOCookie.

  • Idle Session Timeout and Cookie Session Time - The Application Domain Level timeouts are not supported in Coexistence mode.

    For Idle Session Timeouts and Session Timeouts, the configuration present in 10g WebGates will be used. For 11g WebGates, the Idle Timeouts and Session Timeouts are defined in the user defined parameters of the DCC WebGate profile. For example, idleSessionTimeout=125 and cookieSessionTime=245 can be provided in the DCC WebGate profile.

    To set the idle timeout and cookie session timeout at the ECC or Tunneled DCC approach, update the setting Session Lifetime and Idle Timeout on the Common Settings screen in the Oracle Access Management Console. For more information, see "Configuring the Server-Side Session Lifecycle" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

9.10 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 9-1, and configure it with the Access Manager 11.1.2.3.0 Server.

    For information about installing 10g WebGate, and configuring it with the Access Manager 11.1.2.3.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.3.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.3.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 9-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.3.0, see "Registering and Managing 10g WebGates with 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 may have the same primary cookie domain. If the primary cookie domain is not set and if you continue on 11g WebGate only, then 10g host-based ObSSOCookie may get timed out, and therefore you may have to re-authenticate on Oracle Access Manager 10g Server to visit protected resources.

9.11 Enabling Coexistence Mode on Access Manager 11.1.2.3.0 Server

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

  1. Launch the WebLogic Scripting Tool (WLST) by running the following command from the location ORACLE_HOME/common/bin:

    On UNIX: ./wlst.sh

    On Windows: wlst.cmd

  2. Connect to the WebLogic Administration Server by running the following command:

    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 host on which WebLogic Administration Server is running.

    port is the port of the WebLogic Administration Server.

    For example:

    connect('weblogic','password','t3://localhost:7001')

  3. Navigate to the domain runtime MBean hierarchy by running the following command:

    domainRuntime()

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

    setCoexistenceConfigWith10G(ldapUrl="ldap_URL",ldapPrinciple="ldap_principle",ldapConfigBase="ldap_configbase",coexCookieDomain="coex_cookie_domain")

    In this command,

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

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

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

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

    Example: setCoexistenceConfigWith10G(ldapUrl="ldap://oidhost.example.com:3689",ldapPrinciple="cn=oamadmin",ldapConfigBase="dc=com,dc=example,dc=abc",coexCookieDomain=".example.com")

    When prompted, enter the LDAP administrator's password.

  5. Enter the LDAP administrator's password.

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

    enableOamAgentCoexistWith10G()

  7. Restart Access Manager 11.1.2.3.0 server.

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

9.12 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.3.0 Server, to update SERVER_LOGOUTURL parameter in the file to point to the Access Manager 11.1.2.3.0 Server's logout URL. The Access Manager 11.1.2.3.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.3.0 Server.

  1. Set the variable SERVER_LOGOUTURL in the logout.html file to the logout URL, as shown in the following example:

    For Coexistence Enabled Using ECC:

    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.

    For Coexistence Enabled Using DCC:

    var SERVER_LOGOUTURL="http://dcc_host:dcc_port/oamsso-bin/logout.pl

  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.3.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.3.0 Server's logout URL. Therefore, WebGate 10g-1 forwards the request to the Access Manager 11.1.2.3.0 server. The Access Manager 11.1.2.3.0 server clears all the sessions.

9.13 Protecting a Mix of SSL and Non-SSL Applications in Coexistence

It is possible that your Oracle Access Manager 10g deployment protects a mix of applications, some over SSL (HTTPS) and others over non-SSL (HTTP). In such deployment scenarios, it is crucial that coexistence is supported in a way that the Single Sign-On (SSO) is not broken across SSL and non-SSL applications. Therefore, additional configurations are needed in such scenarios to ensure that the ObSSOCookie is available to both SSL and non-SSL applications.

In DCC and DCC Tunneling based approaches, the ObSSOCookie set for coexistence is governed by the obssoCookieCoExConfig parameter. To set ObSSOCookie as not secure, complete the following steps:

  1. Locate the DCC or DCC Tunneling WebGate in Access Manager 11.1.2.3.0 deployment, used for coexistence.

  2. For this 11g WebGate, add the following new user-defined parameter in the user-defined parameters section:

    obssoCookieCoExConfig=disableSecure

  3. Save the changes.

For more information about the user-defined WebGate parameters, see "About User-Defined WebGate Parameters" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

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

9.15 Disabling Coexistence Feature

After migrating all the artifacts of Oracle Access Manager 10g server to Access Manager 11.1.2.3.0 server, you can decommission the Oracle Access Manager 10g server and stop running the Access Manager 11.1.2.3.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.3.0 server to stop running the Access Manager 11.1.2.3.0 server in coexistence mode with Oracle Access Manager 10g.

    disableOamAgentCoexistWith10G()

  3. Restart the Access Manager 11.1.2.3.0 server.

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

    Note:

    It is assumed that /identity/oblix is protected.

  3. Log in with any valid credentials.

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

  4. Restart Access Manager 11.1.2.3.0 server to configure the coexistence mode.