The section A Generalized Example of the Policy Decision Process describes a deployment that emphasizes the similar tasks performed by web agents and J2EE agents. The two agent types share various other features and tasks that are not described in that section. Though this section describes similarities of the two agent types, the features and tasks that they have in common tend to have some differences. However, those differences are often subtle. A list of key features and tasks that web agents and J2EE agents have in common follows along with an explanation of each item:
Configuration properties for both agent types tend to be very similar in terms of functionality.
All agent configurations have an OpenSSOAgentBootstrap.properties file. Regardless of the configuration type, local or centralized, a small subset of properties that are required for the agent to start up and initialize itself are stored in the bootstrap file locally on the server where the agent is installed. This bootstrap file can only be configured by editing it directly. You cannot use either OpenSSO Enterprise Console or the ssoadm command-line utility to edit this file.
When the agents are installed using a centralized configuration (an option available starting with Policy Agent 3.0), both agent types allow the configuration properties, except those located in the OpenSSOAgentBootstrap.properties file, to be configured using either OpenSSO Enterprise Console or the ssoadm command-line utility.
If an agent is configured locally on the agent host, then for both agent types, the properties that are not stored in the bootstrap file must be configured by directly editing the OpenSSOAgentConfiguration.properties file.
Web agents and J2EE agents can log access information and diagnostic information to an agent log file. Each agent has its own log file, a flat file located on the same host system as the agent. The log file size is configurable. When the active log file reaches the size limit, the log is rotated, which means that the older log information is moved and stored in another log file.
Furthermore, both agent types are capable of logging access information to an OpenSSO Enterprise log file or database table.
Both agent types support not-enforced lists. These lists allow for the regular authentication and authorization processes to be bypassed. Two types of not-enforced lists exist: a not-enforced URI/URL list and a not-enforced IP Address list.
A not-enforced URI/URL list is a list of URIs or URLs that are not protected by an agent.
Web agents support a not-enforced URL list. For example, http://agentHost:port/myapp
J2EE agents support a not enforced URI list. For example, /myapp/index.html.
A resource represented by a URI/URL on a not-enforced URI/URL list is widely available, without restrictions. This list can be set to have a reverse meaning. With a reverse meaning, only URIs/URLs on the list are protected. All other URIs/URLs are not protected.
A not-enforced IP Address list is a list of IP addresses that are automatically allowed access to resources. When a user is using a computer that has an IP address on the not-enforced IP address list, that user is allowed access to all the resources protected by the respective agent.
Both agent types can fetch and pass along personal profile attributes, session attributes, and policy response attributes. Client applications protected by an agent can then use information from these attributes to personalize content for the user.