Oracle Access Manager SSO Request Flow

http://www.oraworld.co.uk/step-by-step-flow-of-user-request-for-sso-via-oracle-access-manager/ 1. The user requests a resource. 2. A WebGate forwards the request to OAM for policy evaluation. 3 OAM: – 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 processing begins. 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 collector. 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 Coherence session. 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: OAMAuthnCookie_. 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.