28.2 Runtime Processing Between OpenSSO Agents and Access Manager

The OAM Server includes an OpenSSO Proxy to handle communication with the OpenSSO Agent and facilitate interoperability with the OpenSSO server.

Single Sign On (SSO) and Single Logout (SLO) between OpenSSO policy agents and the OAM Server, for instance. Interoperability is accomplished by honoring HTML/HTTP Authentication requests for end-user authentication (as an HTTP redirect) and XML/HTTP SSO requests for end-user session validation.

Figure 28-1 shows a deployment that includes OpenSSO and Access Manager. The OpenSSO Agent resides with the Web/Java EE container and the protected resource. The OpenSSO Server resides on a different host.

Figure 28-1 Typical Deployment with OpenSSO and Access Manager

Description of "Figure 28-1 Typical Deployment with OpenSSO and Access Manager"

Table 28-4 describes SSO processing between Access Manager and OpenSSO Agents.

Table 28-4 Access Manager Processing with OpenSSO

Functionality	Description
OpenSSO Agent Authentication	OpenSSO agents are authenticated and a valid agent session is established before user authentication. The OpenSSO agent authenticates itself to the OAM Server through the OpenSSO Proxy. OpenSSO Agent Authentication (Agent authenticating itself to the OpenSSO Proxy occurs based on the Agent type: J2EE Agents: Upon Agent container startup. Web Agents: With the first user authentication request to the Web Server. End user sends a request to access an application or resource protected by the OpenSSO agent. OpenSSO agent redirects this un-authenticated user to the OAM Server for authentication as follows: J2EE Agents: Upon Agent container startup. Web Agents: With the first user authentication request to the Web Server. Agent sends the naming request to the proxy to fetch all the other service URLs (Authentication service, Session Service, and so on). Agent sends the xml Authentication request to the Proxy with its credentials on the Authentication service endpoint (obtained from the naming request in Step 3). Proxy authenticates the Agent against an Agent authentication module and creates a non-expiry session in the proxy layer itself. Proxy sends the Authentication xml Response with the agent session details to the agent over http. Once the agent is authenticated, a valid agent session is created. The key that is generated following agent authentication is stored in the Partner and Trust store.
SSO User Login and Authentication	After the agent is authenticated by the OAM Server, the user request is authenticated by the OAM Server. SSO is then provided to the authenticated user accessing resources protected by the agent. After the OpenSSO agent is authenticated and logged in, the agent verifies whether the user has an OpenSSO cookie. If not, the user authentication request is initiated from the OpenSSO agent. User Login OpenSSO agent intercepts the request to protected application. OpenSSO agent checks if the user has an OpenSSO cookie. If not, OpenSSO agent redirects the user to the OpenSSO Proxy for authentication service. OpenSSO Proxy fetches the requested resource URL and the agent ID. The OpenSSO Login event in the OpenSSO proxy wraps this request in a way that the core login events can understand. The OpenSSO login event passes the resource URL and the agent ID to the core login event. Core Login events are performed, which checks if the request object contains an OAM_ID cookie. If yes, OAM Server checks if the session represented by the OAM_ID cookie is a valid session. If the session represented by the OAM_ID cookie is valid, core login event returns the Login response event, which is wrapped by the OpenSSO Login event and is passed on to the OpenSSO login response handler. Core login event returns the identifier of the validated session. OpenSSO login response handler (part of OpenSSO proxy) creates an OpenSSO session identifier in the format that the OpenSSO agent understands and extends this identifier with the OAM session identifier. OpenSSO cookie is created, which contains the OpenSSO session identifier and this cookie is set in the user's browser.
End User Session Validation	OpenSSO agents intercept the request to the protected application. End user Session Validation OpenSSO agent intercepts the request to the protected application and finds an OpenSSO cookie. OpenSSO agent constructs an XML/HTTP request to validate this OpenSSO cookie. Here XML request would have Application / Agent token ID and session ID. This request reaches the OpenSSO proxy layer. OpenSSO Proxy gets the Application Token associated with the request and validates the Application Token with the OAM Server. OAM Server validates the token and sends the response to the OpenSSO Proxy If the Application Token is invalid, the OpenSSO proxy communicates that to the OpenSSO agent and OpenSSO agent starts the agent authentication flow to obtain that valid Application Token. If the Application Token is valid, OpenSSO proxy decrypts the OpenSSO cookie, fetches the OpenSSO session ID and gets the OAM session ID which is stored as the extension in the OpenSSO session ID. The OpenSSO Proxy triggers the session validation flow. If the session represented by the OAM session ID valid, the OpenSSO proxy communicates that to the Agent and the protected application is displayed to the user. This session validation returns the session data (session attributes and values) to the proxy layer as the output of session validation event response. If the session is invalid, authentication flow is initiated by the OAM Server, where the OAM Server collects the user credentials and validates the user.
User profile attributes retrieval for Web Agent types	OpenSSO agents can request user profile attributes once the user is successfully logged in and a valid session is created, by providing the session ID. The OpenSSO proxy layer must receive these requests and fetch the OAM session ID from the OpenSSO session ID extension. OpenSSO Web agents use the Policy service URL for these requests. OpenSSO proxy then fetches these attributes and passes the session ID to the OAM Server (which uses the responses framework to fetch the User Profile attributes and return the data to the OpenSSO Proxy).
User profile attributes retrieval for J2EE Agent types	OpenSSO J2EE agents use jax-rpc calls to retrieve user profile attributes. The flow is similar as the one for Web agents types to retrieve these properties.
User Single Logout	The OpenSSO Proxy receives a User logout request and forwards the user to the OAM logout URL OpenSSO Proxy decrypts the OpenSSO cookie, fetches the OpenSSO session identifier and, from that, fetches the OAM session ID. OpenSSO proxy sends the logout request to controller through the OpenSSO logout event with the OAM session ID. Core logout events are performed, which includes the controller calls to the SSO engine to confirm the session exists. If the session exists, the OAM_ID cookie is deleted, and global logout is performed. The SSO engine returns the response to the controller indicating the session has been cleared. The controller sends a request to the proxy to clear tokens. The Proxy sends the request to the agent to clear tokens through the OpenSSO Logout response handler.
SSO Agent Logout	Access Manager handles single logout requests originating from the OpenSSO agents. Note: The user must be logged out from resources protected by other agents (WebGate and MOD_OSSO, for instance). Agent logout is not required other than in the multi-domain environment. The OpenSSO Agent requests logout to OpenSSO Proxy. The Proxy fetches the Application token from the request and verifies that the request is initiated by an authenticated agent. Opensso Agent Logout is handled within the proxy as the session is created in an independent Agent Session Management Module. The decrypted token is returned to the OpenSSO Proxy. If there is no OpenSSO token present, steps 2 and 3 are absent. The OpenSSO Login event in the OpenSSO proxy wraps this request in a way that the core login events can understand. Core Login events are performed, which includes forwarding the request to the SSO Engine through the controller and authenticating the user. A new session is created for the authenticated user. Core login event returns the Login response event, which is wrapped by the OpenSSO Login event and is passed on to the OpenSSO login response handler. OpenSSO login response handler sends the response to the OpenSSO agent.
Token Generation for OpenSSO Agents	Access Manager processes the tokens generated for, and to be consumed by the OpenSSO agents.
Logging	Enables you to track events during end user access enforcement for following events, using the OAM Server log component: Login success and login failure events Logout success and logout failure events Log messages at different logging levels (FATAL, ERROR, WARNING, DEBUG, TRACE), each of which indicates severity in descending order.
Auditing	Using the OAM Server audit component to: Audit Login events Audit Logout success events
Polling	Polling is not Supported. Only Session Destroy notifications are supported by the OpenSSO Proxy.