How SSO works in OAM 11g

How SSO works in OAM 11g Here at Oracle, the access management PM team gets asked a lot of questions about how Oracle Access Manager 11g works, especially about the overall SSO model, what cookies are created and what they do, and processing flows between components, and how specific component interactions work to achieve authentication and SSO. In this post, we will explore the OAM 11g SSO model. It’s quite a bit different from the OAM 10g model, especially since we now support things like server side credential collection, server-based session management, and application scoped sessions. Before we get started, it’s worth noting that OAM 11g supports the use of both OAM 10g and 11g Webgates as well as mod_osso plug-ins for Oracle HTTP Server (OHS). We support this through what we call the Protocol Compatibility Framework, which lets the OAM server communicate with and interpret protocol messages from the webtier agents mentioned above. This is an extensible framework so has the potential to support other clients or agents in the future. OAM 11g uses a combination of host cookies or domain cookies (depending on the version of Webgate you use), a server cookie, and an in-memory session store (based on Oracle Coherence technology) to maintain and correlate user session information. Since OAM 11g supports different Webgate versions and mod_osso, you will see different cookies depending on the version of Webgate being used, you will either see the ObSSOCookie (for 10g) or OAMAuthnCookie_host:port (for 11g). However in both cases, the contents of the cookies are: Authenticated User Identity (User DN) Authentication Level IP Address SessionID (Reference to Server side session – OAM11g Only) Session Validity (Start Time, Refresh Time) Session InActivity Timeouts (Global Inactivity, Max Inactivity) Validation Hash These cookies are updated periodically using an algorithm of 1/4 of idle session timeout. There are two main differences between the 10g and 11g cookies: The 10g ObSSOCookie is domain scoped and cookie encryption uses a shared key for all 10g Webgates. The 11g OAMAuthnCookie is hosted scoped and different host cookies may be issued for each resource accessed that is protected by a different 11g Webgate. Cookie encryption for each 11g Webgate is unique to that Webgate. The values of the cookies will change over the life of a user's session, however you'll notice that the Session ID that is present is a reference to the server side session object, which remains the same across the life of a session. In the typical deployment topology, you’ll have one or more Webgates deployed on web servers in the Web Tier, a variety of components deployed in the App Tier including an OAM admin server running on the Weblogic domain’s admin server, one or more OAM runtime servers deployed on Weblogic managed servers, a database to support the OAM policies, an LDAP directory against which you will authenticate users, an optional auditing database, and an optional BI Publisher instance for reporting. Using an OAM 11g Webgate in the flow, let’s recap how this works: 1) An OAM 11g Webgate intercepts the incoming request for a resource, determines whether the resource is protected, and – if it is – the OAM 11g server constructs and returns a response back to the Webgate. That response contains the authentication scheme required to authenticate the user. 2) Next the Webgate sets a cookie (called OAM_REQ) to keep track of the target/requested URL and then redirects to the OAM 11g server, which routes the request to the credential collector. The credential collector serves up the login page, which captures credentials and posts the credentials to the OAM server. The credentials are validated against the ID store configured for this particular authentication scheme. Once the credentials are validated, the OAM server creates an authentication token, the session in Coherence, and creates a server side session cookie called the OAM_ID cookie, which has details about the user, the time the session was created, the idle timeout, and session identifier to the coherence session. 3) 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 OAMAuthnCookie, which is set as a host cookie: OAMAuthnCookie_. (In this step if you are using an OAM 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.) 4) 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. As the result of authorization checks, additional attributes may be added to HTTP Headers and passed to downstream applications. This is especially useful when asserting user identity and group or role information to downstream applications such as those running on Oracle WebLogic Server and Oracle Fusion Middleware. 5) When requesting a resource protected by a second Webgate, the request flow will be similar to the above. Webgate2 will check if the resource is protected, and get the authn scheme details from the OAM server. From there WG2 redirects to the OAM server, the OAM server checks the OAM_ID cookie, and then generates a new authentication token for WG2, creates an encrypted response using the key for WG2, and redirects to WG2. WG2 decrypts the response, extracts the authentication token and session identifiers and sets an OAMAuthnCookie as a host cookie for W courtsey : http://oracleaccessmanagement.blogspot.com/2011/03/here-at-oracle-access-management-pm.html