The new resource authentication feature (as documented Resource Authentication Type in OpenSSO Express 8) can also be enabled for deployments that use OpenSSO policy agents - either Web Agents or J2EE Agents. To enable resource authentication, a URL in the agent profile must be modified by appending to it the resource=true query parameter. The attribute that contains this URL is dependent upon whether the policy agent is configured in Cross Domain SSO (CDSSO) or not.
The procedure requires appending the "resource=true" query parameter to the "OpenSSO Login URL"
or "CDSSO Servlet URL" field as follows:
Log into the OpenSSO console as administrator.
Click the Access Control tab.
Click the name of the appropriate realm.
Click the Agents tab.
Click the appropriate agent tab (Web or J2EE).
Click the name of the agent profile to modify.
Choose the appropriate sub step based on whether the agent is configured in CDSSO mode or not.
For an agent running in CDSSO mode, click the SSO tab and append resource=true to the existing value of the CDSSO Servlet URL attribute. For example, http://opensso.sun.com:8080/opensso/cdcservlet?resource=true.
For an agent NOT running in CDSSO mode, click the OpenSSO Services tab and append resource=true to the existing value of the OpenSSO Login URL attribute. For example, http://opensso.sun.com:8080/opensso/UI/Login?resource=true.
As Spandau Ballet once sang so beautifully, it's True.
If your OpenSSO deployment architecture includes a reverse proxy server, you have the option of protecting the content servers by installing a policy agent on the proxy itself, or installing multiple policy agents on the content servers behind the reverse proxy server. The choice is dependent on the relative uniformity or variability of the hosted/protected content and the access-denied URLs.
NOTE: A reverse proxy server or a load balancer with a reverse proxy feature is usually installed between the outer firewall and the inner firewall - in the demilitarized zone (DMZ) between the internet and the secure intranet.
Using a Single Agent
When there is a uniformity in the configuration of the content servers in the back-end (including access denied URLs, application logout URLs, profile, session and response attributes, and the web container type), a single policy agent for the reverse proxy server would be the efficient way of protecting the content. The following diagram illustrates this.
Regardless of the number of content servers being fronted by the reverse proxy, only one agent is installed on the reverse proxy machine. The footprint of this configuration is less cost (fewer agents to maintain) and less memory (a single agent requires less memory to cache). With one agent no communication will occur between the content servers and the OpenSSO server. The policy agent will have back channel communications with the OpenSSO load balancer to update cache entries, perform session validation, and make policy requests but, since the agent is installed on the reverse proxy server and not on the content servers, only the reverse proxy server would communicate with the OpenSSO load balancer. This effectively reduces the number of communication channels which would result in fewer firewall rules, tighter control over server-to-server communications, and a higher level of security.
Using Multiple Agents
When a number of content servers use different types of web containers or each content server has different access denied URLs, agent profiles, session and response attributes, and application logout URLs, the only choice is to install multiple policy agents. Each agent will have its own customized agent profile.
Unlike in the case of the single reverse proxy server policy agent where the same session identifier is used to access many applications protected by the agent, multiple policy agents do not use the same session identifier (when the agents are configured in cookie hijacking prevention mode). With multiple agents, it is now easy to customize agent properties per content server; for example, customize profile attributes to be fetched, session attributes to be fetched, response attributes to be added to the header, URL of the access denied page, customized application error pages, and application logout URLs. (By customizing each application's logout URL, it is possible to perform cleanup tasks (destroying the user's session or resetting cookies) per application.
See the following links for more information.
Notwithstanding the break neck speed at which the blog on new policy agent properties was posted, I found another new property specific to the J2EE agent.
This property is used when the agent is installed behind a proxy or load balancer. Often time the client IP address returned by request.getRemoteAddr() is that of the proxy or load balancer - not the real client IP. The proxy or load balancer may set the real client IP in an X-Forward-IP header so, setting the property com.sun.identity.agents.config.client.ip.header equal to X-Forward-IP will make the agent retrieve the real client IP address from this header to use in the policy evaluation.
And from a secret agent property to a Secret Agent - here's the smash hit theme from the television series Secret Agent called Secret Agent Man as interpreted by Johnny Rivers.
Who knew he played the guitar?
Policy agents function based on a set of configuration properties. Previously, these properties were stored in the AMAgent.properties file that resides on the same machine as the agent. With centralized agent configuration, OpenSSO moves most of the agent configuration properties to the configuration data store.
Agent profiles can be configured to store properties locally (on the machine to which the agent was deployed) or centrally (in the configuration data store), making this new function compatible with both older 2.x agents and newer 3.0 agents. Agent configuration data is now relegated to the following:
FAMAgentBootstrap.properties\* contains bootstrap data and is stored on the agent machine. This file indicates the location from where the configuration properties need to be retrieved. It is used by agents profiles configured locally or centrally.
FAMAgentConfiguration.properties\* contains local configuration data and is stored on the agent machine. It is only used by agent profiles configured locally.
The configuration data store holds the remainder of the agent configuration data.
With agent configuration centralized, an administrator is able to manage multiple agent configurations from the OpenSSO console. Most of the agent properties are hot swappable. (Properties can be modified without rebooting the underlying agent web container.) Additionally, notification of the agent when configuration data changes and polling by the agent for configuration changes is enabled. Agents can also receive notifications of session and policy changes.
NOTE: The configuration change notification does not contain the new data; it is just a ping that, when received, tells the agent to make a call to OpenSSO and reload the latest. Session and policy notifications, on the other hand, contain the actual data changes. Also, when using a load balancer, the notification is sent directly to the agent whose configuration has been changed. It does not go through the load balancer.
The figure below illustrates how an agent retrieves bootstrapping and local configuration data, and configuration data from the configuration data store.
Now that you've got an idea about centralized agent configuration in OpenSSO, how about checking out the Icelandic entry in Eurovision 2008. Here's Euroband singing This Is My Life.
\*UPDATE: Thanks to Sean for the properties files update.