Oracle Access Manager is a key component of Oracle Identity Management, and we saw in previous article the value OAM brings to an enterprise. Lets dive a bit deeper in this article into OAM. We know how OAM saves us from repeatedly entering passwords for different applications in an enterprise. For beginners it is important to note that Oracle Access Manager can be used only to protect applications or services which can be accessed over http/https protocol
i.e. of the format: http(s)://<hostname>:<port>/URL
.
Let us now discuss the functional implementation of OAM i.e. how SSO really happens.
Primary components in OAM that takes part in Single Sign On process are:
Agents -> Webgate
OAM server -> Policy Server
Webgate: It is like a security guard, guarding the resource (or application). Once the Webgate is setup, it intercepts all http(s) based request. It acts as a policy enforcement point (PEP).
OAM Server: After intercepting the request, Webgate passes the request to OAM server. OAM server acts as Policy Decision Point (PDP). If resource is a protected resource, it checks for the authentication and authorization policy attached with it. User is authenticated based on the authentication policy against the configured user identity store (can be OID, AD, or any of the configured LDAP). Once the user is authenticated, it checks for the authorization policy. It may be possible that a user is authenticated; however he/she is not authorized to access the resource. Hence OAM server acts as the policy server, based on the policy attached to the resource it takes the necessary action.
Consider at apps2fusion.com we setup a new transport portal for our employees such that they can manage and update their shift schedule on their own to avail cabs.
Suppose it is accessible at http://apps2fusion.com/transport-helpdesk.
· When the first time user logs in to the system and goes to the application, he will be challenged with the default Single Sign On page to enter username and password. After entering the details, OAM server will validate the user credentials against the user identity store. If the user is valid (entry is found in the store), he/she is authenticated. The type of authentication to be performed can be set in authentication policies.
· Once the user is authenticated, OAM server checks for authorization details. It might be possible that authenticated user is just a blog reader or guest contributor at apps2fusion.com, hence does not have necessary privilege to access the transport portal. These are known as authorization policies which can be configured separately in OAM
· After successful authentication and authorization of the user, it creates a user session which contains all the user information, so when a subsequent request is made in same session, it will read the old session information and user will able to access the resource without entering his credentials again.
How OAM handles the request and provides a Unified Experience to End Users
Technical Details:
As shown above, when a user tries to access http://apps2fusion.com/transport-helpdesk, Webgate intercepts the request (acts as Policy enforcement point) and passes to OAM (acts as policy decision point). If the resource is a protected resource, OAM 11g constructs a response and returns to Webgate.
Response => contains authentication scheme required to authenticate the user.
WebGate sets a cookie (OAM_REQ) to keep the track of target/requested URL an then redirects to OAM 11g server, which then redirects to credential collector. Credential collector presents a login page and posts to oam server. The credentials are validated against the configured ID store.
Once credentials are validated, server side session cookie is created OAM_ID, which has session details.
OAM server then 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 OAMAuthnCookie, which is set as a host cookie: OAMAuthnCookie_host.
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, and does the appropriate authorization checks
OAM_ID cookie is scoped to the OAM Server. OAM_ID is generated by the OAM Server when the user is challenged for credentials, and submitted to the server on every redirect to the server.
OAM_ID is protected by keys known to the OAM Server only.
When a user attempts to access a protected application, the request comes to the SSO Engine and the controller checks for the existence of the cookie, if the cookie does not exist, user authentication begins. After successful authentication, the user context and token are set by the SSO Engine. The cookie is set with the global user ID (GUID), creation time, and idle timeout details. Information in the cookie is encrypted with the SSO Server key and can be decrypted only by the SSO Engine.
If the cookie exists, then the cookie is decrypted and the sign in flow completes with the authenticated user.
Apps2Fusion Articles 