test

Sun Java System Access Manager Policy Agent 2.2 Release Notes

Policy Agent 2.2-01 J2EE Agents

This section on 2.2-01 J2EE agents consists of the following subsections:

The first subsection that follows explains how to determine the version of a Policy Agent 2.2 J2EE agent. For example, you could determine if a hot patch has been applied or not.

Subsequently in this section is a subsection that describes the important fixes and enhancements introduced during the various Policy Agent 2.2 J2EE agent hot patches and a subsection explaining the important new properties introduced.

For the complete list of known problems fixed and enhancements made, see the README provided in the J2EE agent download.

Determining the Version of a Policy Agent 2.2 J2EE Agent

The method for determining the specific version of an installed Policy Agent 2.2 J2EE agent is by using the command line. With this method, you can find the version info, such as the hot patch version, if applicable.

In the PolicyAgent-base/bin directory, issue the agentadmin --version command, where PolicyAgent-base represents the directory where the J2EE agent is installed.

Key Fixes and Enhancements in Policy Agent 2.2-01 J2EE Agents

This section lists the key fixes and enhancements introduced in the Policy Agent 2.2 J2EE agent hot patches, which are now rolled into the 2.2-01 update release. The initial issue is described with its associated change request (bug) number. Furthermore, a short summary is provided about the fix.

If you restart Access Manager but not the J2EE agent, future attempts to access an agent protected page from a browser result in a 403 Forbidden message (6636155)

This problem was fixed in Access Manager 7.0 patch 7 (CR 6496155), but the problem still exists in Access Manager 7.1.

Workaround: Two workarounds exist:

IBM WebSphere Administration Console can not be used to access the users, roles and group identities in the Access Manager identity repository (6462779)

This problem stems from the custom registry that Policy Agent adds for IBM WebSphere Application Server and applies to the following agents:

In terms of Agent for IBM WebSphere Application Server 6.1, the fix was integrated into the original version of the agent.

In terms of Agent for IBM WebSphere Application Server 5.1.1 and Agent for IBM WebSphere Application Server 6.0, this fix enables you to use the WebSphere Administration Console to map the Access Manager roles, groups, and user identities to local J2EE roles that are specific to IBM WebSphere Application Server for authorization purposes. Furthermore, being able to use the WebSphere Administration Console in this manner eliminates the necessity of manually editing the admin-authz.xml file or using the Policy Agent agentadmin --setGroup command.

For the fix to work, you must also implement specific tasks as described in these Release Notes. The instructions apply to Agent for IBM WebSphere Application Server 5.1.1 and Agent for IBM WebSphere Application Server 6.0. See Policy Agent 2.2–01: Enabling Access Manager Identities to Access the IBM WebSphere Administration Console.

The Key New Properties Added for Policy Agent 2.2-01 J2EE Agents

Property Made Available: com.sun.identity.enableUniqueSSOTokenCookie

Change Request:

6636155

The default setting for this property is true. This property was not specifically added to the J2EE agent AMAgent.properties configuration file, but simply made available. Therefore, to set this property to false, which is required to solve the issue described in If you restart Access Manager but not the J2EE agent, future attempts to access an agent protected page from a browser result in a 403 Forbidden message (6636155), you must add both the property name and the value as follows:


com.sun.identity.enableUniqueSSOTokenCookie = false

Policy Agent 2.2–01: Enabling Access Manager Identities to Access the IBM WebSphere Administration Console

This section includes instructions necessary to take advantage of a fix implemented in Policy Agent 2.2–01 specific to agents for IBM WebSphere Application Server.

The instructions in this section apply to the following agents:

The instructions in this section do not apply to Agent for IBM WebSphere Application Server 6.1 since the instructions for that agent are integrated into the following guide: Sun Java System Access Manager Policy Agent 2.2 Guide for IBM WebSphere Application Server 6.1.

Policy Agent 2.2: Problem Accessing Identities With IBM WebSphere Administration Console

In Policy Agent 2.2, the custom registry added by the agents for IBM WebSphere Application Server did not allow the IBM WebSphere Administration Console to access the users, roles and group identities in the Access Manager identity repository.

The respective guides, Sun Java System Access Manager Policy Agent 2.2 Guide for IBM WebSphere Application Server 5.1.1 and Sun Java System Access Manager Policy Agent 2.2 Guide for IBM WebSphere Application Server 6.0 provide tasks that allow you to add J2EE roles for authorization: manually editing admin-authz.xml or executing agentadmin --setGroup option. However, those tasks do not work in an IBM WebSphere cluster deployment. Furthermore, those tasks are error prone and should be avoided.

After you implement the instructions in To Install and Configure Policy Agent 2.2–01 for IBM WebSphere Application Server, you can solely use IBM WebSphere Administration Console to map the local users and groups to Access Manager roles, groups and users.

Policy Agent 2.2–01: Overview of Fix for IBM WebSphere Administration Console Access Problem

After you upgrade Agent for IBM WebSphere Application Server Policy Agent 2.2 to Policy Agent 2.2–01, you must implement the instructions,To Install and Configure Policy Agent 2.2–01 for IBM WebSphere Application Server, to fix the console problem. For more information about the problem this fix addresses, see IBM WebSphere Administration Console can not be used to access the users, roles and group identities in the Access Manager identity repository (6462779). This fix also removes the constraint that remote node operations must be carried out by logging in as serverId, which is supplied in the custom user registry

Caution – Caution –

Specific guidelines for case sensitivity must be adhered to, as follows:

Supplemental Instructions for Installing and Configuring Policy Agent 2.2–01 for IBM WebSphere Application Server

The instructions describe supplemental steps for installing and configuring Policy Agent 2.2–01 for IBM WebSphere Application Server 5.1.1 or 6.0. Use the instructions in conjunction with the appropriate agent guide, Sun Java System Access Manager Policy Agent 2.2 Guide for IBM WebSphere Application Server 5.1.1 or Sun Java System Access Manager Policy Agent 2.2 Guide for IBM WebSphere Application Server 6.0 and with the appropriate Access Manager documentation. The instructions include examples that serve to clarify the type of actions you can take. The examples include the following:

Example Identities:

wasagentuser

WasAgentRole

Example Access Manager Version:

Access Manager 7.1

While you can use Access Manager 6.3 or Access Manager 7.0 with Policy Agent 2.2–01, the examples provided in the instructions that follow use Access Manager 7.1.

Therefore, links to Access Manager documentation are specifically to Access Manager 7.1 documentation. If you are using a different version of Access Manager, consult the appropriate documentation.

The instructions that follow include supplemental pre-installation, installation, and post-installation steps for Policy Agent 2.2–01.

ProcedureTo Install and Configure Policy Agent 2.2–01 for IBM WebSphere Application Server

  1. Create a user in Access Manager.

    Example user: wasagentuser

    This user is the user ID to use while installing the agents and adding the custom user registry in the Deployment Manager (In this scenario, serverId would be wasagentuser). For more information on creating a user, see To Create or Modify a User in Sun Java System Access Manager 7.1 Administration Guide.

    Note –

    When you install the agent for IBM WebSphere Application Server, enter the same name in the agent-profile-name prompt that you have created for the user in this step. For example, wasagentuser. The following example prompt is from the agent installer and illustrates the proper response in this scenario:


    Enter a valid agent profile name. Before proceeding with the agent 
installation, please ensure that a valid Agent profile exists in Access Manager.
[ ? : Help, < : Back, ! : Exit ]
Enter the Agent Profile name: wasagentuser

  2. Create a role in Access Manager.

    Example role: WasAgentRole

    For more information on creating a role, see To Create or Modify a Role in Sun Java System Access Manager 7.1 Administration Guide.

  3. Add the newly created user (wasagentuser) to the newly created role (WasAgentRole).

    For more information about adding users to roles, see To Add Users to a Role or Group in Sun Java System Access Manager 7.1 Administration Guide.

  4. Add the appropriate privilege to the newly created role (WasAgentRole).

    The privilege to use varies according to the Access Manager version as follows:

    • Access Manager 7.0:

      Assign the “Read only access to data stores” privilege to the newly created role (WasAgentRole).

    • Access Manager 7.1:

      Assign the “Read and write access only for policy properties” privilege to the newly created role (WasAgentRole).

    For more information about adding privileges to roles for Access Manager 7.1, see Defining Privileges for Access Manager 7.1 in Sun Java System Access Manager 7.1 Administration Guide or Defining Privileges for an Access Manager 7.0 to 7.1 Upgrade in Sun Java System Access Manager 7.1 Administration Guide.

  5. Edit the Access Manager AMConfig.properties file to allow the agent to get a non-expiring SSO token to Access Manager

    This step is required to get a non-expiring SSO token for the agent's self authentication to Access Manager.

    You must edit the following property to include the distinguished name (DN) of the user (wasagentuser):


    com.sun.identity.authentication.special.users

    If you have a server farm, you must perform this step on all servers.

    Use the legacy SDK DN not the universal UID of the user. For the example presented in this task, the appropriate setting is as follows:


    com.sun.identity.authentication.special.users = cn=dsameuser,
ou=DSAME Users, ROOT_SUFFIX|cn=amService-UrlAccessAgent, ou=DSAME Users,
ROOT_SUFFIX|uid=dmgr,ou=people,ROOT_SUFFIX|
uid=wasagentuser,ou=people,ROOT_SUFFIX

    Where ROOT_SUFFIX is a place holder that represents the root suffix of the directory user management node. For example, dc=example, dc=com. Ensure that this suffix exists in the instance of the directory server you are using.

    Note –

    To find the DN of the user, you can issue an ldapsearch command with the following base:


    ou=people,ROOT_SUFFIX

    And with the following filter:


    (|(uid=wasagentuser)(cn=wasagentuser))

  6. Restart Access Manager.

  7. Add the following properties and corresponding values to the J2EE agent AMAgent.properties configuration file:


    com.sun.identity.agents.config.privileged.attribute.type[1] = Group 
com.sun.identity.agents.config.privileged.attribute.tolowercase[Group] = false

    This step has to be performed on all instances of Agent for IBM WebSphere Application Server that are participating in an agent farm or cluster.

  8. Restart WebSphere Deployment Manager.

  9. Synchronize all the nodes.

Next Steps

Now you can log in to the IBM WebSphere Network Deployment Server's Administration Console to allow authorization to Access Manager that would enable access to the applications deployed in an IBM WebSphere cluster.