For a very high level overview of OAM, check this.
Now here is the step by step flow of a user request that will help in understanding the role of various components involved in SSO via OAM.
1. The user requests a resource.
2. A WebGate forwards the request to OAM for policy evaluation.
– Checks for the existence of an SSO cookie
– Checks policies to determine whether the resource is protected and, if so, how
4. The OAM server logs and returns decisions.
5. The WebGate responds as follows:
– Unprotected Resource
The resource is served to the user.
– Protected Resource
The request is redirected to the credential collector.
The login form is served, based on the authentication policy.
The authentication processing begins.
6. The user sends credentials.
7. OAM verifies the credentials.
8. OAM starts the session and creates the following host-based cookies:
– One per partner: OAMAuthnCookie set by 11g WebGates (ObSSOCookie set by 10g WebGates) using the authentication token received from the OAM server after successful authentication
Note: A valid cookie is required for a session.
One for the OAM server: OAM_ID
9. OAM logs Success or Failure.
10. A credential collector redirects the request to the WebGate and the authorization
11. The WebGate prompts OAM to look up policies, compare them to the user’s identity,
and determine the user’s level of authorization.
12. OAM logs policy decision and checks the session cookie.
13. The OAM server evaluates authorization policies and caches the result.
14. The OAM server logs and returns decisions.
15. The WebGate responds as follows:
– If the authorization policy allows access, the desired content or applications are
served to the user.
– If the authorization policy denies access, the user is redirected to another URL
determined by the administrator.
OAM 11g WebGate Request Flow
1. The OAM 11g WebGate intercepts a request, determines whether the resource is
protected, and if it is, the server returns a response with the authentication scheme that
is required to authenticate the user.
2. The WebGate sets the OAM_REQ cookie to keep track of the target or requested URL,
and then redirects to the OAM 11g server, which routes the request to the credential
3. The credential collector serves up the login page, which captures the credentials and
posts them to the OAM server.
4. After the credentials are validated, the OAM server creates an authentication token, the
session in Coherence, and sets the OAM_ID cookie, which has details about the user,
the time the session was created, the idle timeout, and a session identifier to the
5. Then the OAM server constructs a response, which is encrypted with the WebGate’s
key, and redirects to the WebGate. The WebGate decrypts the response, extracts the
authentication token and the session identifier, and uses that information to set an
OAMAuthnCookie, which is set as a host cookie:
Note: If you are using a 10g WebGate, the response from the server will contain the
information required to set ObSSOCookie.
If you are using mod_osso, the response will contain the information required to set the OHS host cookie.
6. When subsequent requests are made from that WebGate, the authentication token is
passed by the WebGate to the OAM server, which validates the authentication token,
checks the validity of the OAM_ID cookie and session timeout, checks the server-side
session object stored in Coherence, and does the appropriate authorization checks.
7. When a resource protected by a second WebGate is requested, the request flow is
similar to the preceding points. WebGate2 (WG2) checks whether the resource is
protected, and gets the authentication scheme details from the OAM server. From there,
WG2 redirects to the OAM server and the OAM server checks the OAM_ID cookie,
generates a new authentication token for WG2, creates an encrypted response by using
the key for WG2, and then redirects to WG2. WG2 decrypts the response, extracts the
authentication token and session identifiers, and sets an OAMAuthnCookie as a host
cookie for WG2.