The Subjects interface enables basic identity management within a realm. Any identity that you create in the Subjects interface can be used in the subject definition in the for a policy created with the Access Manager Identity Subject type.
The identities you can create and modify are:
Click on the User tab.
Enter data for the following fields:
UserId. This field takes the name of the user with which he or she will log into Access Manager. This property may be a non-DN value.
First Name. This field takes the first name of the user.
Last Name. This field takes the last name of the user.
Full Name — This field takes the full name of the user.
Password. — This field takes the password for the name specified in the User Id field.
Password (Confirm) — Confirm the password.
User Status. This option indicates whether the user is allowed to authenticate through Access Manager.
Once the user is created, you can edit the user information by clicking the name of the user. For information on the user attributes, see the User attributes. Other modifications you can perform:
Click the name of the user you wish to modify.
Select Roles or Groups. Only the roles and groups that have already been assigned to the user are displayed.
Select the roles or groups from the Available list and click Add.
Once the roles or groups are displayed in the Selected list, click Save.
Select the identity to which you wish to add services.
Click on the Services tab.
Depending on the identity type you selected, the following list of services are displayed:
Liberty Personal Profile Service
Select the service you with to add and click Next.
Edit the attributes for the service. For a description of the services, click on the service name in Step 4.
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)
A filtered role is a dynamic role created through the use of an LDAP filter. All users are funneled through the filter and assigned to the role at the time of the role’s creation. The filter looks for any attribute value pair (for example, ca=user*) in an entry and automatically assign the users that contain the attribute to the role.
In the Navigation pane, go the organization where the role will be created.
Enter a name for the filtered role.
Enter the information for the search criteria.
If the filter is left blank, by default, the following role is created:
(objectclass = inetorgperson)
Click Create to initiate the search based on the filter criteria. The identities defined by the filter criteria are automatically assigned to the role.
Once the filtered role is created click the name of the role to view the Users that belong to the role. You can also add services to the role by clicking the Services tab.
A role’s members are LDAP entries that posses the role. The criteria of the role itself is defined as an LDAP entry with attributes, identified by the Distinguished Name (DN) attribute of the entry. Once the role is created, you manually add services and users.
Click the name of the role or group for which you wish to add users.
Click the Users tab.
Select the users you wish to add from the Available list and click Add.
Once the users are displayed in the Selected list, click Save.
A group represents a collection of users with a common function, feature or interest. Typically, this grouping has no privileges associated with it. Groups can exist at two levels; within an organization and within other managed groups.