19 Coexistence of Sun Java System Access Manager 7.1 with Oracle Access Management Access Manager 11.1.2

This chapter describes how to set up an environment where both Sun Java System Access Manager 7.1 and Oracle Access Management Access Manager (Access Manager) 11g Release 2 (11.1.2) deployments coexist, after you migrate from Sun Java System Access Manager 7.1 to Access Manager 11.1.2.

This chapter contains the following sections:

19.1 Coexistence Overview

During the process of migration from Sun Java System Access Manager 7.1 to Oracle Access Manager 11.1.2, you can have both Sun Java System Access Manager 7.1 and Access Manager 11g deployments coexisting, such that some applications are protected by Sun Java System Access Manager 7.1 while others are protected by Access Manager 11.1.2. It is desirable for end-users to have a seamless single sign-on experience when they navigate between these applications. This is called coexistence mode.

In this mode, Access Manager 11.1.2 protects the migrated applications and any new applications registered with Access Manager 11.1.2; whereas Sun Java System Access Manager 7.1 continues to protect the applications that are not migrated to Access Manager 11.1.2.

In this coexistence mode, Sun Java System Access Manager 7.1 performs the authentication for all the resources protected by Access Manager 11.1.2.

19.2 Coexistence Topology

Figure 19-1 illustrates how the authentication is done by the Sun Java System Access Manager 7.1 Server when a user requests to access a protected resource.

Figure 19-1 Coexistence of Sun Java System Access Manager 7.1 with Access Manager 11.1.2

Description of Figure 19-1 follows
Description of "Figure 19-1 Coexistence of Sun Java System Access Manager 7.1 with Access Manager 11.1.2"

The topology consists of disjoint Sun Java System Access Manager 7.1 and Access Manager 11.1.2 environments. The numbers 1-8 in the topology show the sequence in which a request flows in the coexistence environment. See Table 19-1 for the request flow.

Topology Description

  • Agent-1: This is the Policy Agent 2.2 that protects Resource-1. This agent needs to communicate with Access Manager 11.1.2 Server. You cannot directly register 2.2 agents in Access Manager 11.1.2 Server. Therefore, you must either register Agent-1 with Sun Java System Access Manager 7.1 and then migrate the profile of this agent from Sun Java System Access Manager 7.1 Server to Access Manager 11.1.2 Server, or you can install a new Policy Agent 3.0 pointing to Access Manager 11.1.2 to protect Resource-1.

  • Agent-2: This is the Policy Agent 2.2 registered with Sun Java System Access Manager 7.1 to protect the end point URL of the Access Manager 11.1.2 Server. You must create a profile for this agent in Sun Java System Access Manager 7.1 Server and install a new policy agent (2.2).

  • Agent-3 and Agent-4: These are the policy agents (2.2) registered with Sun Java System Access Manager 7.1.

  • Resource-1: This is a resource which is protected by Agent-1 which talks to the Access Manager 11.1.2 Server.

  • Policy-1: This is the policy created on Access Manager 11.1.2 server for protecting Resource-1. This policy is created as part of the task: Creating an Authentication Policy in Access Manager 11.1.2 to Protect Resource-1.

  • Policy-2: This is the policy created on Sun Java System Access Manager 7.1 Server for opensso proxy endpoints of Access Manager 11.1.2 protected by Agent-2. This policy is created as part of the task: Protecting Access Manager 11g Server's End Point URL by Agent-2.

Table 19-1 describes the request flow. The numbers in the Step column correspond to the numbers shown in the topology in Figure 19-1.

Table 19-1 Request Flow

Step Description

1

User requests to access Resource-1 which is protected by Agent-1 that communicates with the Access Manager 11.1.2 Server.

2

Agent-1 redirects the user to Access Manager 11g Server for authentication (…./opensso/UI/Login.....?goto=resource1) using the authentication scheme OAM10gAuthScheme as per Policy-1. The user authenticated by Sun Java System Access Manager server is set in the OAM_REMOTE_USER header by the OpenSSO agent. Hence, Agent-1 uses the authentication scheme OAM10gAuthScheme to assert the user from header OAM_REMOTE_USER.

3

The Access Manager 11.1.2 Server end point is protected by Agent-2 that communicates with the Sun Java System Access Manager 7.1 Server.

Therefore, Agent-2 redirects the user to the Sun Java System Access Manager 7.1 Server for LDAP authentication (...opensso/UI/Login?goto=<…./oam/server/.....?goto=resource1>) as per Policy-2.

4

The Sun Java System Access Manager 7.1 server's LDAP authentication module prompts the user for LDAP user name and password. User must enter the valid LDAP credentials.

5

The Sun Java System Access Manager 7.1 Server validates the user credentials, and creates user session as OpenSSO Enterprise 8.0 session and sets the OpenSSO Enterprise 8.0 SSO cookie1 with this session ID.

6

Sun Java System Access Manager 7.1 server redirects the user to the Access Manager 11.1.2 Server (…./opensso/UI/Login/.....?goto=resource1.

7

Agent-2 verifies the user session and policy evaluation by ensuring the presence of Sun Java System Access Manager 7.1 session cookie 1. It now provides access to Access Manager 11.1.2 Server (…./opensso/UI/Login/.....?goto=resource1) after setting the header OAM_REMOTE_USER to the userID in Session Attribute Mapping.

The Access Manager 11.1.2 Server invokes OAM 10g Authentication scheme (OAM10gAUthScheme) as per step 2 (Policy-1).The Access Manager 11.1.2 server asserts the user using the header OAM_REMOTE_USER, using the OAM10gScheme configured for the Resource-1.

8

The Access Manager 11.1.2 Server creates Access Manager session and sets headers. It also sets the OAM_ID cookie and Sun Java System Access Manager SSO cookie2 (via OpenSSO Proxy), and redirects the user to Resource-1. Sun Java System Access Manager 7.1 SSO cookie2 has link to the related OAM_ID cookie.

The user can now access Resource-1, as Agent-1 verifies the user session and policy evaluation by ensuring the presence of Sun Java System Access Manager session cookie2 and OAM_ID cookie.


19.3 Task Roadmap

Table 19-2 lists the steps to configure the coexistence environment.

Table 19-2 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, Completing the Prerequisites

3

Create Agent-2 profile on the Sun Java System Access Manager 7.1 Server, and install Agent-2. Update the web applications ngsso-web.war and openssoproxy-urlmapper.war in oam-server.ear file.

Also, create a policy on Sun Java System Access Manager 7.1 to protect the end point URL of Access Manager 11.1.2 Server 11.1.2 by Agent-2.

See, Protecting Access Manager 11g Server's End Point URL by Agent-2

4

Configure the data sources for Access Manager 11.1.2.

See, Configuring Data Source for Access Manager 11.1.2

5

Update the authentication module in Access Manager 11g, and point the user identity store to the data source that is configured in Section 19.6.

See, Updating LDAPNoPasswordAuthModule in Access Manager 11g

6

Migrate the profile of Agent-1 from Sun Java System Access Manager 7.1 to Access Manager 11.1.2.

See, Migrating the Profile of Agent-1 from Sun Java System Access Manager 7.1 to Access Manager 11.1.2

7

Create an authentication policy on the Access Manager 11.1.2 Server to protect Resource-1.

See, Creating an Authentication Policy in Access Manager 11.1.2 to Protect Resource-1

8

Change the default cookie name of Access Manager 11.1.2, so that the cookie names of Access Manager 11g and Sun Java System Access Manager 7.1 are different.

See, Changing the Default Cookie Name of Access Manager 11.1.2 Server to a New Name

9

Update the profile of Agent-2 in Sun Java System Access Manager 7.1 Server with the right Session Attributes Mapping.

See, Updating the Profile of Agent-2 in Sun Java System Access Manager 7.1 Server

10

Configure logout setting to initiate logout from both Sun Java System Access Manager 7.1 Server and Access Manager 11.1.2 Server.

See, Configuring Logout Settings

11

Verify the configuration.

See, Verifying the Configuration


19.4 Completing the Prerequisites

Complete the following prerequisites before you start performing the tasks described in this chapter:

19.5 Protecting Access Manager 11g Server's End Point URL by Agent-2

You must create a profile for Agent-2 in Sun Java System Access Manager 7.1, and freshly install a policy agent 2.2 to protect the end point URL of the Access Manager 11.1.2 Server. Also, you must create a policy for protecting the end-point URL of the Access Manager 11g Server in the Sun Java System Access Manager 7.1 Server. To do this, perform the following tasks:

  1. Creating the Profile of Agent-2 for Access Manager on Sun Java System Access Manager 7.1 Server

  2. Installing Agent-2 (Policy Agent 2.2)

  3. Updating Web Applications to Include Agent Filter Configurations

  4. Creating Policy on Sun Java System Access Manager 7.1 Server for Access Manager

19.5.1 Creating the Profile of Agent-2 for Access Manager on Sun Java System Access Manager 7.1 Server

Create Agent-2 profile (as shown in Figure 19-1) on the Sun Java System Access Manager 7.1 Server by doing the following:

  1. Log in to the Sun Java System Access Manager 7.1 server console using the URL:

    http://host:port/amserver
    

    In this URL,

    • host refers to fully qualified domain name of the machine hosting the Sun Java System Access Manager 7.1 console (administration server)

    • port refers to the designated bind port for the Sun Java System Access Manager 7.1 console

  2. Go to the Access Control tab.

  3. Click the top realm under Realm Name column in Realms table.

  4. Go to the Subjects tab, and click the Agent tab.

  5. Click New to create the new Agent-2, and specify the necessary details about the agent.

  6. Click OK.

19.5.2 Installing Agent-2 (Policy Agent 2.2)

Install Agent-2 (Policy Agent 2.2) in front of Access Manager.

For more information about installing Policy Agent 2.2, see "Installing the Policy Agent for WebLogic Server/Portal 10" in the Sun Java System Access Manager Policy Agent 2.2 Guide for BEA WebLogic Server/Portal 10.

19.5.3 Updating Web Applications to Include Agent Filter Configurations

Update the web applications ngsso-web.war and openssoproxy-urlapper.war to include the agent filter configurations in the web.xml file for the Access Manager 11.1.2 Server to be protected by Agent-2. To do this, complete the following steps:

  1. Unzip the oam-server.ear file from the location IAM_HOME/oam/server/apps/oam-server.ear, and extract the contents to a temporary directory.

  2. Extract the contents of the ngsso-web.war file, and then extract the contents of web.xml file. Update the web.xml file with the appropriate agent filter configuration for the Access Manager 11.1.2 server to be protected by Agent-2. Update the filter definition with the URL /server/opensso/login/* in url-pattern.

    For example:

    <filter>
    <filter-name>Agent</filter-name>
    <filter-class>com.sun.identity.agents.filter.AmAgentFilter</filter-class>
    </filter>
    <filter-mapping>
    <filter-name>Agent</filter-name>
    <url-pattern>/server/opensso/login/*</url-pattern>
    </filter-mapping>
    
  3. Extract the contents of the openssoproxy-urlmapper.war file at the same location IAM_HOME/oam/server/apps/oam-server.ear. Update the web.xml file with the appropriate agent filter configuration for the Access Manager 11.1.2 Server to be protected by Agent-2. Update the filter definition with the URL /UI/* in url-pattern.

    For example:

    <filter>
    <filter-name>Agent</filter-name>
    <filter-class>com.sun.identity.agents.filter.AmAgentFilter</filter-class>
    </filter>
    <filter-mapping>
    <filter-name>Agent</filter-name>
    <url-pattern>/UI/*</url-pattern>
    </filter-mapping>
    
  4. Re-package the oam-server.ear file to include the updated ngsso-web.war and openssoproxy-urlapper.war files.

  5. Redeploy the updated oam-server.ear file.

19.5.4 Creating Policy on Sun Java System Access Manager 7.1 Server for Access Manager

You must create an policy (referred to as Policy-1) on Sun Java System Access Manager 7.1 Server to protect the end point URL of the Access Manager 11.1.2 server. To do this, complete the following steps:

  1. Log in to the Sun Java System Access Manager 7.1 Server console using the URL:

    http://host:port/amserver
    

    In this URL,

    • host refers to the fully qualified domain name of the machine hosting the Sun Java System Access Manager 7.1 console (administration server).

    • port refers to the designated bind port for the Sun Java System Access Manager 7.1 console, which is the same as the bind port for the administration server.

  2. Click the Access Control tab.

  3. Click the top realm under Realm Name column in Realms table.

  4. Click the Policies tab.

  5. Click New Policy, and provide the details of the new policy for protecting the end point URL of Access Manager 11.1.2 Server with Rule as OAM_server_protocol://OAM_server_host:OAM_managed_server_port/opensso/UI/Login*?*, and OAM_server_protocol://OAM_managed_server_host:OAM_managed_server_port/oam/server/opensso/login*, and Subject as Authenticated Users.

  6. Click OK.

19.6 Configuring Data Source for Access Manager 11.1.2

Configure the data source for Access Manager 11.1.2 by completing the following steps:

  1. Log in to the Oracle Access Manager 11.1.2 console using the following URL:

    http://host:port/oamconsole
    

    In this URL,

    • host refers to the 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 console, which is the same as the bind port for the administration server

  2. Go to the System Configuration tab.

  3. Select Common Configuration.

  4. Expand Data Sources, and select User Identity Stores

  5. Under User Identity Stores, create a new data source by clicking the Create icon on the top of the left panel. This data source must be of type ODSEE. You must provide the details of the Sun Java System Directory Server used by Sun Java System Access Manager 7.1 as configuration and user store.

19.7 Updating LDAPNoPasswordAuthModule in Access Manager 11g

You must update the authentication module used by OAM10gScheme to point to the data source created in section 20.6 as its User Identity Store. To do this, complete the following steps:

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

    http://host:port/oamconsole
    
  2. Go to the System Configuration tab.

  3. Expand Access Manager, and then expand Authentication Modules.

  4. Expand LDAP Authentication Module.

  5. Click LDAPNoPasswordAuthModule, and update the user identity stores to point to the data source that you created in Section 19.6.

19.8 Migrating the Profile of Agent-1 from Sun Java System Access Manager 7.1 to Access Manager 11.1.2

Agent-1 is the Policy Agent (2.2) that protects Resource-1. This agent should be a 2.2 Web Agent, and should communicate with the Access Manager 11.1.2 Server. But the 2.2 agents cannot be directly created in Access Manager 11.1.2. Therefore, you must register Agent-1 with Sun Java System Access Manager 7.1, and then migrate the profile of Agent-1 from the Sun Java System Access Manager 7.1 Server to Access Manager 11.1.2 Server.

For information on migrating the profile of Agent-1 from Sun Java System Access Manager 7.1 to Access Manager 11.1.2, see Chapter 16, "Migrating Sun Java System Access Manager 7.1 Environments".

Note:

When completing the procedure to migrate the profile of Agent-1 to Access Manager 11.1.2, update the agent profile of Agent-1 alone in section 17.7.3 "Updating the Agent Profile for 2.2 Agents", since you need to migrate Agent-1 alone.

Make sure you do not create any policies protecting the resources that are intercepted by Agent-1 (or resources on this agent's host or port) in Sun Java System Access Manager 7.1.

If you do not wish to migrate the profile of Agent-1 (Web Agent 2.2) to Access Manager 11.1.2, you can create the profile of Agent-1 in Access Manager 11.1.2, and install a new Policy Agent 3.0 pointing to the Access Manager 11.1.2 Server to protect Resource-1.

If Agent-1 is a 2.2 J2EE Agent, you must create the profile of Agent-1 in Access Manager 11.1.2, and install a new Policy 3.0 J2EE Agent pointing to the Access Manager 11.1.2 Server to protect Resource-1. This is because, the migration of 2.2 J2EE Agents to Access Manager 11.1.2, and the creation of 2.2 agents in Access Manager 11.1.2 are not supported.

For information about creating the profile of agent in Access Manager 11.1.2, see "Registering and Managing OpenSSO Policy Agents Using the Console" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

For information about installing Policy Agent 3.0, see the respective guide in the Sun OpenSSO Enterprise 8.0 Documentation Library.

19.9 Creating an Authentication Policy in Access Manager 11.1.2 to Protect Resource-1

Create an authentication policy (referred to as Policy-2) under the appropriate application domain to protect Resource-1 with the authentication scheme named OAM10gScheme.

Also, create an authorization policy for Resource-1 with the condition TRUE. The resource URLs configured should be "/" and "/.../*".

For more information on creating and managing authentication and authorization policies, see "Managing Policies to Protect Resources and Enable SSO" in the Oracle Fusion Middleware Administrator's Guide for Oracle Access Management.

19.10 Changing the Default Cookie Name of Access Manager 11.1.2 Server to a New Name

You must change the default cookie name of the Access Manager 11.1.2 Server to a new name in order to avoid conflict between the cookie names of Access Manager 11.1.2 and Sun Java System Access Manager 7.1 servers. To do this, complete the following steps:

  1. Stop the WebLogic Administration Server and the Access Manager 11.1.2 Managed Servers.

    For more information about stopping the Administration Server and the Managed Servers, see "Starting and Stopping Administration Servers" and "Starting and Stopping Managed Servers" in the Oracle Fusion Middleware Administrator's Guide.

  2. Open the oam-config.xml file from the location IAM_HOME/user_projects/domains/base_domain/config/fmwconfig/oam-config.xml.

  3. Increment the value of the parameter Version by one in the oam-config.xml file.

  4. Under the section openssoproxy, modify the value of openssoCookieName from the default cookie name iPlanetDirectoryPro to a different value (for example: OAMSAMCookie).

  5. Start the WebLogic Administration Server and the Access Manager 11.1.2 Managed Servers.

    For more information about starting the Administration Server and the Managed Servers, see "Starting and Stopping Administration Servers" and "Starting and Stopping Managed Servers" in the Oracle Fusion Middleware Administrator's Guide.

  6. Log in to the Oracle Access Management 11.1.2 console using the following URL:

    http://host:port/oamconsole
    
  7. Go to the System Configuration tab.

  8. Expand Access Manager, and then expand SSO Agents.

  9. Expand OpenSSO Agents.

  10. Select the required Agent-1, and update the cookie name with the new value (for example, OAMSAMCookie).

  11. Restart the Access Manager 11.1.2 Server.

19.11 Updating the Profile of Agent-2 in Sun Java System Access Manager 7.1 Server

You must update the Session Attribute Mapping for Agent-2 to set the header OAM_REMOTE_USER to the value of UserToke in AMAgent.properties file. To do this, complete the following steps:

  1. Open the AMAgent.properties file from the location where you installed Agent-2.

  2. Set the following values in the properties file:

    • com.sun.identity.agents.config.session.attribute.fetch.mode=HTTP_HEADER

    • com.sun.identity.agents.config.session.attribute.mapping[UserToken]=OAM_REMOTE_USER

  3. Restart the web container instance of Agent-2.

19.12 Configuring Logout Settings

You must configure logout settings to have single logout across Sun Java System Access Manager 7.1 and Access Manager 11.1.2 in coexistence mode. To do this, you must follow the procedure described in the following two sections:

19.12.1 Settings to Initiate Logout from Sun Java System Access Manager 7.1 Server

To initiate logout from Sun Java System Access Manager 7.1 Server, you must write a post authentication plug-in, and implement onLogout() method, and set the query parameter goto to the redirect URL <OAM_server_protocol>://<OAM_server_host>:<OAM_managed_server_port>/opensso/UI/Logout. This redirects the user to the end point URL of the Access Manager 11.1.2 server.

19.12.2 Settings to Initiate Logout from Access Manager 11g Server

To initiate logout from the Access Manager 11.1.2 server, you must update the Logout URL in the respective Policy Agent 2.2 (Agent-1) configured with Access Manager 11.1.2 Server to redirect to the Sun Java System Access Manager 7.1 Server logout end point. To do this, complete the following steps:

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

    http://host:port/oamconsole
    
  2. Go to the System Configuration tab.

  3. Expand Access Manager, and then expand SSO Agents.

  4. Expand OpenSSO Agents.

  5. Select the Agent-1, (that is configured with Access Manager 11g and is protecting Resource-1), and set the Logout URL to redirect to Sun Java System Access Manager 7.1 server logout end point (SAM7.1_server_protocol://SAM7.1_server_host:SAM7.1_managed_server_port/amserver/UI/Logout), with goto query parameter set to the redirect URL configured for Agent-1.

    For example: If the Logout URL already configured is protocol://OAMHOST:OAMPORT/opensso/UI/Logout , it must be modified to protocol://OAMHOST:OAMPORT/opensso/UI/Logout?goto=SAM7.1_server_protocol://SAM7.1_server_host:SAM7.1_server_port/amserver/UI/Logout?goto=any url agent wants to be redirected to after logout

19.13 Verifying the Configuration

To verify the configuration, complete the following steps:

  1. Access Resource-1. Observe that you are redirected to the Sun Java System Access Manager 7.1 server for authentication. After the authentication, you can access Resource-1.

  2. Access any resource protected by Agent-3 (as shown in Figure 19-1), and observe that an explicit login is required to access the resource.

  3. Initiate logout from both the Sun Java System Access Manager 7.1 Server and Access Manager 11.1.2 Server, and observe that all the three cookies (cookie1, cookie2, and OAM_ID cookie) are cleared.