What’s New About J2EE Agents in This Release

Several important features have been added to J2EE agents in release 2.2 as follows:

• Removal of Dependencies on LDAP and on Administrative Accounts

• Enhanced Installation Process

• Coexistence With Access Manager

• Support for Client Identification Based on Custom HTTP Headers

• Agent Specific Application for Housekeeping Tasks

• URL Policy Enhancements

• Support for Flexible User Mapping Mechanisms

• Support for Fetching User Session Attributes (J2EE Agents)

• Support for Version Checking

• Support for Not-Enforced IP Lists

• Support for Custom Response Headers

• Support for Application Logout Integration

• Support for Application Specific Agent Filter Operation Modes

• Support for Affinity-Based Login URL Selection

• Support for a Sample Application

• J2EE Agents and Backward Compatibility With Access Manager 6.3

Removal of Dependencies on LDAP and on Administrative Accounts

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.

Enhanced Installation Process

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.

Coexistence With Access Manager

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.

Support for Client Identification Based on Custom HTTP Headers

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.

Agent Specific Application for Housekeeping Tasks

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.

URL Policy Enhancements

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.

Support for Flexible User Mapping Mechanisms

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.

Support for Fetching User Session Attributes (J2EE Agents)

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.

Support for Version Checking

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.

Support for Not-Enforced IP Lists

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.

Support for Custom Response Headers

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.

Support for Application Logout Integration

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

Support for Application Specific Agent Filter Operation Modes

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.

Support for Affinity-Based Login URL Selection

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.

Support for a Sample Application

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.

J2EE Agents and Backward Compatibility With Access Manager 6.3

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.