Access Manager Policy Agents protect content on web servers and web proxy servers from unauthorized intrusions. They control access to services and web resources based on the policies configured by an administrator.
The agent object defines a Policy Agent profile, and allows Access Manager to store authentication and other profile information about a specific agent that is protecting an Access Manager resource. Through the Access Manager console, administrators can view, create, modify and delete agent profiles.
the agent object creation page is the location where you can define the UID/password with which the the agent authenticated to Access Manager. If you have a multiple AM/WS setup using the same Access Manager, this gives you the option of enabling multiple IDs for different agents and to enable and disable them independently from Access Manager. You can also manage some preference values for the agents centrally, rather than editing the AMAgent.properties on each machine.
Click the Agents tab.
Enter the values for the following fields:
Name. Enter the name or identity of the agent. This is the name that the agent will use to log into Access Manager. Multi-byte names are not accepted.
Password. Enter the agent password. This password must be different than the password used by the agent during LDAP authentication.
Confirm Password. Confirm the password.
Device Status. Enter the device status of the agent. 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.
Once you have crated the agent, you can additionally edit the following fields:
Description. 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.
Agent Key Value. Set the agent properties with a key/value pair. This property is used by Access Manager to receive agent requests for credential assertions about users. Currently, only one property is valid and all other properties will be ignored. Use the following format:
By default, when you create multiple policy agents in a trusted environment, the policy agents contain the same UID and password. Because the UID and passwords are shared, Access Manager cannot distinguish between the agents, which may leave the session cookie open to interception.
The weakness may be present when an Identity Provider provides authentication, authorization and profile information about a user to application(s) (or Service Providers) that are developed by third parties or by unauthorized groups within the enterprise. Possible security issues are:
All applications share the same http session cookie. This makes it possible for a rogue application to hijack the session cookie and impersonate the user to another application.
If the application does not use the https protocol, the session cookie is prone to network eavesdropping.
If just one application can be hacked, the security of the entire infrastructure is in jeopardy of being compromised.
A rouge application can use the session cookie to obtain and possibly modify the profile attributes of a user. If the user has administrative privileges, the application would be able to do a lot more damage.
Use the Access Manager administration console to make an entry for each agent.
Run the following command on the password that was entered during the creation of the agent. This command should be invoked on the host where the agent is installed.
This will give the following output:
Change AMAgent.properties to reflect the new value, and then and restart the agent. Example:
# The username and password to use for the Application authentication module. com.sun.am.policy.am.username = agent123 com.sun.am.policy.am.password = WnmKUCg/y3l404ivWY6HPQ== # Cross-Domain Single Sign On URL # Is CDSSO enabled. com.sun.am.policy.agents.cdsso-enabled=true # This is the URL the user will be redirected to after successful login # in a CDSSO Scenario. com.sun.am.policy.agents.cdcservletURL = http://server.example.com:port /amserver/cdcservlet
Change AMConfig.properties where Access Manager is installed to reflect the new values, and then and restart Access Manager. Example:
com.sun.identity.enableUniqueSSOTokenCookie=true com.sun.identity.authentication.uniqueCookieName=sunIdentityServerAuthNServer com.sun.identity.authentication.uniqueCookieDomain=.example.com
In the Access Manager console, choose Configuration>Platform.
In the Cookie Domains list, change the cookie domain name:
Select the default iplanet.com domain, and then click Remove.
Enter the host name of the Access Manager installation, and then click Add.
You should see two cookies set on the browser:
iPlanetDirectoryPro – server.example.com (hostname)
sunIdentityServerAuthNServer – example.com (hostname)