In Policy Agent 2.2, web agents and J2EE agents offer a variety of new features as described in the following sections:
These sections describe the new features available.
Several important features have been added to the web agents in the 2.2 release as follows:
Additional Method for Fetching the REMOTE_USER Server Variable
Web Agents and Backward Compatibility With Access Manager 6.3
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.
Starting with this release of web agents, when the current log file reaches a specific size, a new log file is created. Log information is then stored in the new log file until it reaches the size limit. This default behavior is configurable. Therefore, log rotation can be turned off and the size limit can be changed.
Starting with this release of web agents, a new method is available for retrieving header 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 policy decisions defined globally in the agent configuration.
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.
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.
Starting with this release of web agents, malicious header attributes are automatically cleared.
Starting with this release of web agents, the default agent hostname, port, and protocol settings can be overridden to enable load balancing.
HTTP requests might pass through an SSL off-loader, load balancer, or proxy server before getting to the web agent. In such cases, the protocol (HTTP scheme), the hostname, or the port of the web agent might be different than that of the SSL off-loader, load balancer, or proxy server. You can set properties in the web agent AMAgent.properties configuration file to ensure that the protocol, hostname, and port of the web agent matches the load balancing mechanism.
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 Sun Java System Web Server 6.1 and an agent instance for Apache 2.0.52 could not be installed on the same machine. Now, they can.
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.
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.
Several important features have been added to J2EE agents in release 2.2 as follows:
Removal of Dependencies on LDAP and on Administrative Accounts
Support for Client Identification Based on Custom HTTP Headers
Support for Application Specific Agent Filter Operation Modes
J2EE Agents and Backward Compatibility With Access Manager 6.3
Unlike previous releases, J2EE agents in the Policy Agent 2.2 release do not use a direct LDAP connection. Instead, J2EE agents obtain support for their entire functionality by communicating with Access Manager solely with XML over HTTP.
With the authorization of administrators now being handled by an agent profile account, the dependence on two administrative accounts, the amAdmin account and the amldapuser account, has been removed. Now, during installation, the agent installer prompts you for the agent profile account.
Starting with this release of J2EE agents, the installation process includes the following features that allow for a smoother, less restrictive, more secure installation process and deployment:
Support for Installation Using Non-Administrative User Accounts
The requirement in prior agent releases that the installation user have root (or Administrator) privileges has been removed. The agent can now be installed by any user regardless of access privileges.
Secure Handling of Sensitive Information
All sensitive information, such as passwords, is now read from files. This information is not typed in clear text during interactive session. Therefore, it is never displayed on the command line or in any logs.
Self-Contained Installation
All agent configuration and log files are generated and maintained within an agent’s installation directory. This installation directory is referred to as the Policy Agent base directory. In code examples this directory is listed as such, PolicyAgent-base. The distribution files for the 2.2 release of J2EE agents are provided to you in three formats. You can choose the format that best fits your needs: zip format, tar format, or a package format. The files are small in size since the installer for this release uses a simple configuration mechanism. In summary, when you unpack the binaries, the configuration and log files remain within the installation directory.
Support for Multiple Physical Installations
There is no longer any restriction on using multiple different binaries of the same agent on the same machine.
Starting with this release, you can deploy a J2EE agent on an instance of an application server where Access Manager has already been installed. Note that Access Manager should be installed prior to the agent being installed.
Starting with this release, J2EE agents can be configured to use custom HTTP headers to identify the remote client IP address and host name. This client IP address is used to validate an Access Manager session or to evaluate applicable policies.
Starting with this release of J2EE agents, a bundled application is available to perform housekeeping tasks on the deployment container, such as an application server.
This bundled application, when deployed on an agent-protected application server instance, expands the agent’s functionality. For example, this bundled application allows the agent to receive notifications and to support cross-domain single sign-on. In previous releases, this functionality was tied to an application referred to as the primary application, which was secured by the agent.
Starting with this release of J2EE agents, the following features are available that enhance Uniform Resource Locator (URL) policy:
Remote Policy Evaluation Failover
J2EE agents can now leverage session failover functionality to ensure that remote policy evaluation failover can occur if an Access Manager instance becomes unavailable.
Configurable Policy Evaluation Mechanism
Starting with this release, J2EE agents can be configured to use two different mechanisms to remotely evaluate policies as follows:
The agent remotely requests policy evaluation for all resources applicable to a user within the agent’s scope of protection.
The agent remotely requests policy evaluation for the resource accessed by the user and not any other resources that the user might access later.
Composite Advice
In the 2.2 release, J2EE 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 writing solely 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.
Policy Based Response Attributes
The policy-based response attribute feature allows the policy service to provide static and dynamic attributes based on the resource accessed by the user. These attributes can be made available to the agent protected application as HTTP headers, request attributes, or cookies.
Starting with this release, J2EE agents provide support for user mapping modes that have flexibility in the user names they choose. In prior releases, a user name had to be an Access Manager user ID. Now, user names can be chosen from a few different sources as long as the names are for authenticated users who have trusted identities. A trusted identity can be established on the agent- protected server for a security principal (or for an equivalent trusted identity of the user). This mechanism allows the agent to choose a user ID for the authenticated user from the user’s profile attributes, the user’s session properties, or an HTTP header accompanying the user request.
Before this release of J2EE agents, information for HTTP headers, request attributes, or cookies was retrieved, or sourced, solely from profile attributes. Now, this information can also be sourced from session properties.
Starting with this release of J2EE agents, you can easily check the exact version of the agent you are using, including build date, build number, and Client SDK version. Prior to this release, administrators could not easily identify the build date of the agent they were using. Since code changes occur between build dates, identifying the exact build can be useful.
Starting with this release, J2EE agents support not-enforced IP lists. With this feature, an agent always grants access to resources when the request comes from a machine with an IP address that appears on a specified list in the agent configuration file.
Starting with this release, J2EE agents provide support for custom response headers. The agent can be configured so that custom response headers are set on every request. Such headers are defined statically in the agent configuration file and are honored on all enforced web resources as identified by the agent.
Starting with this release, J2EE agents can be configured to identify an application logout event and to synchronize the event with the Access Manager logout. The agent can identify the logout of an application based on preconfigured information sent with a request as follows:
The request URI
A query parameter sent with the request
A request parameter sent within the request body
The application-specific filter operation mode mechanism allows different applications to use different levels of protection as necessary. Different filter operation modes provide different levels of functionality, thus enabling the selection of the best mode for each protected application.
Starting with this release, J2EE agents support a prioritized (or an affinity-based) selection of login URLs for authenticating users. End users are directed to the URL highest on the list if it is available. If not, the second URL on the list is targeted. If a URL higher on the list becomes available again, the agent switches to that URL.
You can disable this affinity-based selection process if desired, which would allow you to use a round-robin selection scheme.
Starting with this release, the J2EE agents provide a bundled sample application to demonstrate the key features and functionality of the agent. Some of the features demonstrated are:
J2EE declarative security
J2EE programmatic security
URL policy-based access control deployed on an agent-protected application server
The sampleapp directory includes the sample application and a README.TXT file explaining how to use the sample application.
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.