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:
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.
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
- 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.
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.
More Here
Courtesy:http://oracleaccessmanagement.blogspot.com/2011/03/here-at-oracle-access-management-pm.html
