Agent for IBM WebSphere Application Server 6.0 functions in a similar manner to all Access Manager J2EE agents in the Policy Agent 2.2 release. However, this agent, as with all agents, functions in accordance to the architecture of the underlying deployment container, which in this case is IBM WebSphere Application Server 6.0. This section describes the key components of this particular agent that enable it to interact with IBM WebSphere Application Server 6.0.
The following information is an overview of the architecture of this agent, which corresponds to the architecture of IBM WebSphere Application Server 6.0. However, you should have a solid understanding of the concepts related to IBM WebSphere Application Server 6.0 before installing and configuring the agent for this deployment container.
Agent for IBM WebSphere Application Server 6.0 is designed to facilitate Single Sign-On (SSO) and enforce access control for application resources hosted by IBM WebSphere Application Server 6.0. When a user requests access to a hosted and protected application resource, the agent ensures the following:
The user has already been authenticated. If not, the agent coordinates with Access Manager Authentication Service to ensure successful user authentication by participating in a choreographed sequence of HTTP interactions. Once authenticated, the user's identity is established within IBM WebSphere Application Server's J2EE container. This identity is further propagated to any down-stream EJB container if the request processing results in access to a resource within that container.
The propagation of the security identity information of a particular user to a down-stream EJB container might require additional configuration changes in some cases. Such cases typically include clustered deployments and other specialized configurations.
The user's privileged attributes are available for membership evaluation of roles and other constraints as required to enforce any declarative or programmatic security policies within the application.
Privileged attributes for a user in an Access Manager environment can range from simple LDAP Role membership information to highly customized attribute information provided via protected session properties. Other examples include custom identity types configured within the Access Manager Identity Repository Service.
Any URL Policies defined within Access Manager Policy Service for securing access to the requested URLs are enforced as necessary.
Agent for IBM WebSphere Application Server 6.0 provides per instance configuration that allows you to enable or disable a part of the above functionality as necessary in certain deployment scenarios. For instance, the agent allows you to choose if the identity of the user should be established within Agent for IBM WebSphere Application Server's J2EE container. Furthermore, the agent provides a great deal of other functionality that allows you to customize its behavior in the most appropriate way to suit your site's deployment.
Agent for IBM WebSphere Application Server 6.0 is composed of three components that interact with each other, directly or indirectly via the IBM WebSphere Application Server 6.0 infrastructure, to facilitate the implementation of key agent functionality. The following is a brief description of each component:
This component uses a standard interface to facilitate SSO and propagate the user membership information to IBM WebSphere Application Server 6.0.
This component uses a standard interface to facilitate the assertion of user membership information within the IBM WebSphere Application Server 6.0 security infrastructure as provided by the front-ending Trust Association Interceptor implementation.
This component uses a standard interface to facilitate advanced functionality such as URL Policy enforcement, logout synchronization, and such, to further secure the application resources and provide a seamless user experience.
During runtime, the agent components interact directly or indirectly via the IBM WebSphere Application Server 6.0 infrastructure to accomplish their functional requirements. In a typical scenario, a client request for a protected application resource will in some way invoke each of these three components and the outcome of this invocation will largely govern the overall success of request processing. The following sequence illustrates how each of these components come into play during various stages of request processing:
The client makes a web request to access a hosted application resource protected by Agent for IBM WebSphere Application Server 6.0.
If the protected resource is protected by a role-based constraint and the user's identity is not yet established, the security infrastructure of IBM WebSphere Application Server 6.0 invokes the Agent's Trust Association Interceptor implementation.
The Trust Association Interceptor implementation ensures that the user is authenticated and populates the corresponding subject with appropriate credentials that are validated by the agent's Custom User Registry implementation. This results in the establishment of the user's security principal in the web tier and allows the security infrastructure to evaluate any membership information for that user as required.
If all the necessary requirements are satisfied, the security infrastructure allows the request to proceed to the application resource being protected. At this stage, the agent's Custom Servlet Filter implementation intercepts the request and enforces the applicable URL Policies. If the request bypassed the last two stages, the Custom Servlet Filter implementation assumes the task of authenticating the user and then performing the required processing. Note that the Custom Servlet Filter implementation does not establish or alter the Subject information associated with the user.