Monday, March 21, 2011

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 WG2.


Shesh Kondi said...


Great blog.
One quick comment on #4 in the SSO flow: Should we also mention that additional attributes can be added to the Session Cookie as well, along with the HTTP header?


Puneet Sharma said...

Very informative. A nice Read !!

Wilfred said...

Would love to make the switch from 10.1.4 SSO to OAM 11, but still waiting for Oracle Forms support. Any news on an ETA?

Eric Leach said...

Wilfred - This certification is complete. As of the Oracle Fusion Middleware 11gR1 PS3 release, Oracle Forms is certified with OAM 11g. We also have the migration utilities and processes documented. You can choose upgrade or a coexistence model. Check out the FMW upgrade guide for IDM:

netcrazy said...

Hi Eric,
With 11g, there are quite many changes in the way cookie handling is done and the security around it. So, are we saying that tools like Firesheep would have a tough time in hijacking / re-using OAM cookie for a non-HTTPS request?


Eric Leach said...


Chris did a great job of providing a more detailed flow on the Fusion Security Blog:

To briefly summarize, OAM 11g manages sessions through the combination of a server side session object (stored in a Coherence cache), a server side authentication token called OAM_ID, and a resource based session cookie called OAM_AuthnCookie which is set by the Webgate and is scoped to the host where that Webgate is configured. (That is, if you are using 11g Webgates. If you are using 10g Webgates then the resource session cookie is the ObSSOCookie, which is domain scoped.)

The idea is to make it more difficult to get at all the bits of data someone would need to replay another user's session and to limit the scope of damage in the event that someone does replay a resource session cookie.

As explained elsewhere (and far more eloquently that I could), the best way to protect against HTTP session hijacking is to require SSL/TLS or other mechanisms to properly encrypt/verify traffic.

netcrazy said...

Is 11g going to give me a functionality to create cookies for multiple domains instead of just one as in 10g? And if yes, then will I have the flexibility to allow SSO between these cross-DC cookies. I'm not referring to federation here.


Anonymous said...

If a simple J2EE or .Net Web Application participates in a OAM11g based SSO solution (with Webgate, AuthN and AuthZ policies all set)...

1) how will this application know which user has logged in to OAM in order to be able to create its own application session so it can keep track of user's activities/data etc.

2) with every request being redirected by Webgate to OAM Server back to Webgate and then back to the application, does it have any impact on the request parameters/attributes present in the original request submitted by the user's browser. How are request/page attributes etc kept intact and made available to the application?

3) with OAM server being the session manager (handling user's session life cycle) when the user's session is destroyed in OAM Server due to reasons like idle timeout or hard-timeout how will the application know that it has to destroy the session on its end?

Is there a document explaining with examples how this integration works. It will be nice if the product comes with some samples and code to clearly demonstrate integration of OAM with web applications developed on different platforms/languages and best practices around using the different response types (Header, Cookie, Session) and when to use AuthN responses vs Authz responses.

Eric Leach said...


I would definitely recommend taking a look at the Fusion Middleware Security Guide, which covers topics like how SSO integrates with applications running on WLS/FMW.

You can find this guide here:

Additionally, take a look at the OAM 11g Admin guide. There is a section on integrating ADF applications with OAM 11g SSO, which should give you a sense of the general integration pattern for JEE or .NET applications. You can find this section here:

We didn't cover this in the post in detail, but you can think about this as two step process: 1) identifying/authenticating the user and 2) asserting the user's identity to the application.

In the first step, you will capture information about the original request so that you can redirect the user back to the originally requested resource once authentication successfully completes.

Typically step #2 is how you identify the user to the application, and this is usually done by asserting the identity in an HTTP Header.

Now if you want to have some synchronicity between OAM managed sessions and application sessions, you will need some infrastructure - such as Oracle Platform Security Services - to bridge between things managed in the application's context and things managed outside of the app context. This configuration is explained in detail in the ADF-OAM integration section of the docs I mention above.

Thanks for the feedback on the samples. We will look at including some additional samples/examples with the product to make this easier to understand.