Several important features have been added to the web agents in the 2.2 release as follows:
Before this release of web agents, header and cookie information was retrieved, or sourced, solely from user profile properties. Now, header and cookie information can also be sourced from session properties.
Use the following property to choose how you want session attributes retrieved:
For the preceding property, the following modes are available as retrieval methods:
The following example illustrates this property with the retrieval method set to HTTP_HEADER:
com.sun.am.policy.agents.config.session.attribute.fetch.mode = HTTP_HEADER
The source of header and cookie information is controlled by the following configuration property in the web agent AMAgent.properties configuration file:
This configuration property has the same format as an LDAP header property. The following is an example of how this configuration property can be set:
com.sun.am.policy.agents.config.session.attribute.map = name-of-session-attribute1|name-of-header-attribute1, name-of-session-attribute2|name-of-header-attribute2
Where name-of-session-attribute1 and other similarly named properties, or attributes, in the preceding code represent actual property names.
Benefit - Support for Fetching User Session Attributes: The benefit of this feature is that session properties can be more effective for transferring information, especially dynamic information. Prior to this release, agents could only fetch users’ profile attributes, which tend to be static attributes. However, session attributes allow applications to obtain dynamic user information when necessary. Since this feature allows you to fetch non-user profile attributes, you can fetch attributes such as SAML assertion.
Log rotation is not supported on Policy Agent 2.2 for Apache HTTP Server. For more information see Information Specific to Agent for Apache HTTP Server
Starting with this release of web agents, a new method is available for retrieving LDAP user attributes based on Access Manager policy configurations.
Policy-based response attributes take advantage of functionality now available in Access Manager that involves querying policy decisions. In previous versions of Access Manager, header attributes could only be determined by the list of attribute-value pairs in the agent configuration. Now, header attributes can also be determined by Access Manager policy configurations. With policy-based response attributes you can define attribute-value pairs at each policy definition as opposed to the method used in prior versions of Access Manager, which only allowed pairs to be defined globally in the agent configuration. For more information on policy-based response attributes, see Providing Personalization With Policy-Based Response Attributes
Benefit - Policy-Based Response Attributes: The benefit of policy-based response attributes is that they allow for personalization, improve the deployment process, allow greater flexibility in terms of customization, and provide central and hierarchical control of attribute values.
Personalization is provided in that an application can retrieve specific user information, such as a name, from a cookie or HTTP header and present it to the user in the browser.
Defining attribute-value pairs at each policy definition instead of at the root level allows an attribute value to be distributed only to the applications that need it. Furthermore, you can customize attribute names allowing the same attribute name to have entirely different property values for two different applications.
Starting with this release, web agents provide a composite advice feature. This feature allows the policy and authentication services of Access Manager to decouple the advice handling mechanism of the agents. This allows you to introduce and manage custom advices by solely writing Access Manager side plug-ins. Starting with this release, you are not required to make changes on the agent side. Such advices are honored automatically by the composite advice handling mechanism.
Benefit - Composite Advice: A benefit of composite advice is that you can incorporate a custom advice type without having to make changes to an agent deployment. Prior to the 2.2 release of web agents, no interface existed on the client side to write client-side plug-ins.
Prior to this release of web agents, the only method for fetching the value of the REMOTE_USER variable set by an agent was from session properties. Starting with the 2.2 release, the value can also be fetched from user profiles. This fetching process uses LDAP.
By default the value for the REMOTE_USER is fetched from the session. If the value needs to be fetched from LDAP, the following property needs to be defined in the web agent AMAgent.properties configuration file:
com.sun.am.policy.am.userid.param.type = LDAP
The following property can still be used to configure the key (key refers to the value assigned to this property) that needs to be searched. In addition to setting the preceding property, you need to give the correct LDAP attribute name for the following property.
For example the property will be set as follows:
com.sun.am.policy.am.userid.param = ldap-attribute-name
where ldap-attribute-name represents the name of an LDAP attribute.
To enable the REMOTE_USER setting for a globally not-enforced URL as specified in the web agent AMAgent.properties configuration file (this is a URL that can be accessed by unauthenticated users) you must set the following property in the web agent AMAgent.properties configuration file to true. While the following example, has the value is set to true, the default value is false:
com.sun.am.policy.agents.config.anonymous_user.enable = true
When you set this property value to true, the value of REMOTE_USER will be set to the value contained in the following property in the web agent AMAgent.properties configuration file. In the following example the value is set to anonymous, which is the default:
com.sun.am.policy.agents.config.anonymous_user = anonymous
Benefit - Additional Method for Fetching the REMOTE_USER Server Variable: The benefit of this feature is that it gives better customization for end users since the REMOTE_USER server variable can now be obtained from either session attributes or user profile attributes.
Also, you do not need to write server-side plug-in code in order to add session attributes after authentication, which is necessary when this value is fetched from session properties.
Starting with this release of web agents, malicious header attributes are automatically cleared.
Benefit - Header Attributes Set by Agents Automatically Cleared: The benefit of this automatic clean up is that security is improved. Header information that is not automatically cleared has greater risk of being accessed.
Starting with this release of web agents, the default agent host port and protocol settings can be overridden to enable load balancing. For more information, see Enabling Load Balancing.
Benefit - Load Balancing Enablement: The benefit of this override capability is that you do not need to manually change the hostname, port, and protocol settings to enable load balancing.
Starting with this release of web agents, you can install different types of agents on the same machine. Prior to this release, you could not install web agents from different product groups on the same machine. For example, previously, an agent instance for Apache HTTP Server and an agent instance for Sun Java System Web Server 6.1 could not be installed on the same machine. Now, they can.
Benefit - Support for Heterogeneous Agent Types on Same Machine: The benefit of this feature is that a deployment that has agents in a multi-server scenario requires fewer hardware sources.
Starting with this release, fully qualified domain name (FQDN) mapping of HTTP requests can be disabled. In prior web agent releases, the methods employed for checking if a user is using a valid URL could not be turned off.
This checking capability is controlled by the FQDN default and the FQDN map properties in the web agent AMAgent.properties configuration file as follows:
A toggling capability has been introduced that allows FQDN checking to be turned off. The following property allows for this toggling:
The following property specifies whether the request URLs that are present in user requests are checked against the FQDN default and the FQDN map properties by the web agent:
The valid values are true and false.
The request URLs that are present in user requests are checked against FQDN values.
No checking occurs against FQDN values.
The default value is true. If no value is specified, then the default value, true, is used.
Benefit - Support for Turning Off FQDN Mapping: This feature allows you to turn off or on FQDN mapping comparison. This feature can be beneficial when a deployment includes a number of virtual servers for which the agent is configured using FQDN mapping.
Policy Agent 2.2 is backward compatible with Access Manager 6.3 Patch 1 or greater.
Policy Agent 2.2 is only compatible with Access Manager 6.3 when the Access Manager patch has been applied.
Be aware that Policy Agent 2.2 takes advantage of certain features that exist in Access Manager 7 that do not exist in Access Manager 6.3, such as “composite advices,” “policy-based response attributes,” and others.