Implementing the Access Manager Solution for Cookie Hijacking Security Issues

The instructions presented in this section provide a solution to the potential risks related to session-cookie hijacking as outlined in this document. This section includes two subsections as follows:

• Creating or Updating an Agent Profile

• Configuring the Access Manager Deployment Against Cookie Hijacking

In Policy Agent 2.2, web agents and J2EE agents use agent profiles in a slightly different way. The information provided in this section on the agent profile explains the differences between the two agent types and provides the actual steps necessary to ensure that each agent has its own agent profile.

This section also provides the other configuration steps necessary to guard web resources in an Access Manager deployment against the threat of session-cookie hijacking.

After you perform the tasks presented in this document, Access Manager starts enforcing restrictions on the sessions it creates. The new configuration enables Access Manager to more closely track aspects of each session. At that point, not only does Access Manager record which agent performed the initial redirection for authentication it also tracks the applications to which an SSO token has been issued. Access Manager uses this information to facilitate the processing of each subsequent request and to prevent unauthorized access to protected web resources.

Creating or Updating an Agent Profile

Since J2EE agents and web agents in the Policy Agent 2.2 software set handle the agent profile differently, the configuration steps can differ. The following table provides information about the agent profile in relationship to the two agent types:

As the preceding table indicates, J2EE agents in the 2.2 release do not provide default credentials for the agent profile. You create an agent profile in Access Manager Console prior to installing the J2EE agent, which allows you to provide information about the agent profile during installation. If you do not create an agent profile, the J2EE agent will not function. Since each successfully installed J2EE agent has a unique agent profile, no further configuration would be required regarding the agent profile credentials.

Web agents, on the other hand, provide default credentials for the agent profile. Be aware that you should not use these web agent default values in an Access Manager deployment configured against cookie hijacking. Instead, create an agent profile for the web agent instance as described in To Create an Agent Profile. For reference purposes, the default credentials for the agent profile of a web agent are provided in the list that follows:

Web agent default agent profile “user ID”

Value. UrlAccessAgent

Location. This user ID is stored in the web agent AMAgent.properties file as the value assigned to the property com.sun.am.policy.am.username.

Web agent default agent profile “password”

Value. The password of the Access Manager internal authentication user. This user is commonly referred to as amldapuser.

Location. This password, which is encrypted, is stored in the web agent AMAgent.properties file as the value assigned to the property com.sun.am.policy.am.password.

The web agent should not use the default agent profile for an Access Manager deployment configured against cookie hijacking. Furthermore, while the J2EE agent installer updates the agent with the agent profile credentials, the web agent installer does not. Therefore, creating an agent profile before installing the web agent, though useful, is not by itself sufficient. You must also configure the web agent AMAgent.properties configuration file by editing the agent profile ID and password as described in To Update the Agent Profile Credentials in the Web Agent.

This document provides guidance for creating or updating agent profiles. However, the steps can vary depending upon the agent type and the status of the agent. While the steps that follow are appropriate for many scenarios, such as for agents that are yet to be installed, the steps are not appropriate for all possible scenarios.

For example, if you are using a J2EE agent that was previously installed, the pre-existing agent profile is appropriate. You would not be required to perform any of the steps presented in this section about creating or updating the agent profile.

However, in terms of a previously installed J2EE agent, if you decide to change the agent profile user ID and password, even though not required, then configuration steps are necessary. Be aware that the steps required in this scenario are not provided in this document. For such a scenario, refer to the Policy Agent 2.2 documentation for information specifically about updating the agent profile.

For more information on creating or updating the agent profile, see the documentation for the specific agent you are using. The individual agent guides are listed along with supported server information in the following chapters of the Sun Java System Access Manager Policy Agent 2.2 User's Guide:

Web Agents

Chapter 2, Access Manager Policy Agent 2.2 Web Agents: Compatibility, Supported Servers, and Documentation, in Sun Java System Access Manager Policy Agent 2.2 User’s Guide

J2EE Agents

Chapter 3, Access Manager Policy Agent 2.2 J2EE Agents: Compatibility, Supported Servers, and Documentation, in Sun Java System Access Manager Policy Agent 2.2 User’s Guide

To Create an Agent Profile

This task is appropriate for web agents and J2EE agents. See the preceding Caution for information about when this task might apply.

Agent profiles apply to specific agents but are created and modified in Access Manager Console. Therefore, tasks related to the agent profile are discussed in Access Manager documentation and Policy Agent documentation, as well as in this document.

Perform the following steps using the Access Manager Console. The key steps of this task involve creating an agent ID and an agent password.

1. With the Access Control tab selected click the name of the realm for which you would like to create an agent profile.

2. Select the Subjects tab.

3. Select the Agent tab.

4. Click New.

5. Enter values for the following fields:

   ID. Enter the name or identity of the agent. This is the agent profile name, which is the name the agent uses to log into Access Manager. Multi-byte names are not accepted.

   Password. Enter the agent password. This password must be different than the LDAP user password used by Access Manager.

   Password (confirm). Confirm the password.

   Device Status. Select the device status of the agent. The default status is Active. If set to Active, the agent will be able to authenticate to and communicate with Access Manager. If set to Inactive, the agent will not be able to authenticate to Access Manager.

6. Click Create.

   The list of agents appears.

7. (Optional) If you desire, add a description to your newly created agent profile:

   1. Click the name of your newly created agent profile from the agent list.

   2. In the Description field, enter a brief description of the agent.

      For example, you can enter the agent instance name or the name of the application it is protecting.

   3. Click Save.

Next Steps

If you performed this task for a web agent, you must also perform the following task about updating the agent profile. If you performed this task for a J2EE agent, you can skip to Configuring the Access Manager Deployment Against Cookie Hijacking.

To Update the Agent Profile Credentials in the Web Agent

This task applies to web agents only, not to J2EE agents. This task description provides alternatives for steps that differ according to platform: UNIX-based systems or Windows systems. For a more thorough explanation about updating the agent profile for a web agent, see the corresponding Policy Agent 2.2 documentation.

1. Update the following property in the web agent AMAgent.properties configuration file:

   com.sun.am.policy.am.username

   Replace the value of this property with the agent profile ID (name) you just updated in Access Manager Console. Therefore, this property would then appear similarly to the following:

   com.sun.am.policy.am.username = agent-profile-ID
   

2. Change directories to the following:

   • UNIX-based Systems

     PolicyAgent-base/bin

   • Windows Systems

     PolicyAgent-base\bin

3. Execute the following script in the command line:

   • UNIX-based Systems

     crypt_util agent-profile-password

   • Windows Systems

     cryptit agent-profile-password

   where agent-profile-password represents the agent profile password you updated in Access Manager Console.

4. Copy the output obtained after issuing the script in the previous step and paste it as the value for the following property:

   com.sun.am.policy.am.password

   This property would appear similarly to the example that follows, where encrypted-password-string is a place holder for the real encrypted password:

   com.sun.am.policy.am.password = encrypted-password-string
   

5. Ensure that protected web resources are accessible.

   1. Restart the web container.

   2. Attempt to access any resource protected by the web agent.

   If the attempt to access a protected resource results in a redirection to Access Manager, then the preceding steps were executed properly.

Configuring the Access Manager Deployment Against Cookie Hijacking

At this point in the configuration, each agent has its own agent profile. However, Access Manager has not been configured yet to associate an SSO token to a specific agent profile. The steps in this section enable this type of association. Ultimately, the new configuration introduces “restricted tokens” into the Access Manager deployment, guarding against security issues as described in this document.

To Configure the Access Manager Deployment Against Cookie Hijacking

This task description includes configuration information for agents in the Policy Agent 2.2 software set. Perform the task on every agent instance for which you want to enhance security. The best practice is to perform the task on all the agent instances in the Access Manager deployment. As part of the configuration of each agent instance, you must also make specific configurations directly to Access Manager. For this task, be prepared to access the Access Manager Administration Console, the agent AMAgent.properties configuration file, the Access Manager AMConfig.properties configuration file, and a browser that can access a protected web resource.

1. Using the Access Manager Administration Console, access the agent profile configuration page.

   For the steps on navigating within the Access Manager Administration Console to the agent profile configuration page, see To Create an Agent Profile.

2. Add the appropriate value to the field labeled Agent Key Value.

   Set the agent properties with a key/value pair as illustrated in the example that follows. This property is used by Access Manager to retrieve an agent profile from an agent repository for credential assertions about agents. Currently, only one property is valid. All other properties are ignored. Use the following format:

   agentRootURL=protocol://hostname:port/

   The preceding entry must be precise. Be aware that the string “agentRootURL” is case sensitive. Also, the slash following the port number is required.

   protocol

   Represents the protocol used, such as HTTP or HTTPS.

   hostname

   Represents the host name of the machine on which the agent resides. This machine also hosts the resources that the agent protects.

   port

   Represents the port number on which the agent is installed. The agent listens to incoming traffic on this port and, from the port, intercepts all requests to access resources on the host.

   The following is an example of how this property could be set:

   agentRootURL=https://agentHost.example.com:8080/

3. Edit the appropriate (J2EE agent or web agent) AMAgent.properties configuration file as necessary.

   1. Set the property that enables CDSSO to true as illustrated:

      • For J2EE agents set the following property as indicated:

        com.sun.identity.agents.config.cdsso.enable = true

      • For web agents set the following property as indicated:

        com.sun.am.policy.agents.config.cdsso.enable = true

      The preceding property setting enables CDSSO, which is required for each agent instance since the agent will use functionality provided by the CDSSO feature.

   2. Set the property that stores the URL users are directed to after they log in successfully in a deployment enabled for CDSSO:

      • For J2EE agents set the corresponding property as suggested by the following example:

        com.sun.identity.agents.config.cdsso.cdcservlet.url[0] = https://amHost.example.com:8080/amserver/cdcservlet

      • For web agents set the corresponding property as suggested by the following example:

        com.sun.am.policy.agents.config.cdcservlet.url = https://amHost.example.com:8080/amserver/cdcservlet

4. Restart the container that hosts the agent.

5. Edit the Access Manager AMConfig.properties configuration file to reflect the required changes.

   1. Set the following property to true as illustrated:

      com.sun.identity.enableUniqueSSOTokenCookie = true

   2. Set the following property exactly as it is illustrated:

      com.sun.identity.authentication.uniqueCookieName = sunIdentityServerAuthNServer

   3. Set the following property to a domain such that it covers all the Access Manager instances installed:

      com.sun.identity.authentication.uniqueCookieDomain

      The following example illustrates how this property would be set if the domain name was example.com.

      com.sun.identity.authentication.uniqueCookieDomain = .example.com

6. In the Access Manager Administration Console, select the Configuration tab.

7. Scroll as needed to the System Properties list and click Platform.

8. In the Cookie Domain list, change the cookie domain name.

   This step enables Access Manager to set host-specific session cookies instead of domain-wide session cookies.

   1. Ensure that the default domain, such as “example.com,” is selected.

   2. Click Remove.

   3. Enter the name of the machine hosting the Access Manager instance.

      For example:

      amHost.example.com

   4. Click Add.

9. Ensure that the proper cookies appear in a browser.

   1. Use a browser to access a resource that is protected by the agent that you just configured.

   2. Check the browser's cookie settings to ensure that the three following cookies appear:

      Cookie Name	Example Cookie Value	Example Cookie Domain Information
      iPlanetDirectoryPro	SSO-token	amHost.example.com
      iPlanetDirectoryPro	restricted-SSO-token	agentHost.example.com
      sunIdentityServerAuthNServer	https://amHost.example.com:8080	.example.com

      For more information about the preceding cookies, see Access Manager Session Cookies Involved in Issuing Unique SSO Tokens.