This section on 2.2-01 J2EE agents consists of the following subsections:
Key Fixes and Enhancements in Policy Agent 2.2-01 J2EE Agents
The Key New Properties Added for Policy Agent 2.2-01 J2EE Agents
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.
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.
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.
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:
Add the following new property to the J2EE agent AMAgent.properites configuration:
com.sun.identity.enableUniqueSSOTokenCookie=false |
For more about setting the value for the preceding property, see Property Made Available: com.sun.identity.enableUniqueSSOTokenCookie.
or
Always restart agent after restarting Access Manager.
This problem stems from the custom registry that Policy Agent adds for IBM WebSphere Application Server and applies to the following agents:
Agent for IBM WebSphere Application Server 5.1.1
Agent for IBM WebSphere Application Server 6.0
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.
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 |
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:
Agent for IBM WebSphere Application Server 5.1.1
Agent for IBM WebSphere Application Server 6.0
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.
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.
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
Specific guidelines for case sensitivity must be adhered to, as follows:
Access Manager group and role identities mapped to an IBM WebSphere Application Server role
For example if you have a role named “WASAdmin” in Access Manager, you must enter “wasadmin” in the IBM WebSphere Administration Console not “WASAdmin” or “WasAdmin.” If you type “WasAdmin,” the console is likely to validate and save the changes. However, a failure will result during access control evaluation because of the mismatch in case. Therefore, always use lower case characters for Access Manager role and group names in the IBM WebSphere Administration Console.
An Access Manager user identity mapped to an IBM WebSphere Application Server user identity
For example, if you have created a user in Access Manager named “WasAdminUser,” use the same case in the IBM WebSphere Administration Console.
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:
wasagentuser
WasAgentRole
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.
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.
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 |
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.
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.
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.
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.
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)) |
Restart Access Manager.
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.
Restart WebSphere Deployment Manager.
Synchronize all the nodes.
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.