OAM cookies

Understanding various Cookies used in OAM (Oracle Access Manager)

Oracle Access Manager (OAM) uses several cookies to track and maintain session information for user sessions. e.g OAM_ID, OAM_REQ, ObSSOCookie. Each cookie and its purpose is given below.

How does the OAM server know which session belong to which user? In other words how does OAM uniquely identify each user session and apply the authentication policy for the particular user and application. This post will cover these in terms of the various cookies that are set and by OAM server/Webgates.

Each cookie is used to provide a function that helps OAM server to create and subsequently track the session of a user, whether the user is authenticated, whether the session is active, or it is Expired. A session can also be in an Inactive state as well.

OAM protects its resources via Application policy set by the administrator for each of the protected resource/application. Each of the Application/resource has a Webgate installed (Webgate is the piece of software or module, or agent which is protecting the application) - a Webgate is an agent of OAM and communicates with the OAM server to check the authentication policy and subsequently grant or deny access to the user request.

When a user is authenticated, OAM creates OAM_ID cookie which is a domain level cookie. OAM_ID cookie is httponly cookie so this cookie cannot be accessed through client side scripts. It contains session ID which maps to the in-memory session. It is only set for Embedded Credential Collector(ECC). (In 11g version there are two modes of OAM configuration - DCC, Detached Credential Collector and ECC, Embedded Credential Collector)

When a user attempts to access a protected application or resource, the OAM server checks for the existence of OAM_ID cookie.

OAMAuthnCookie: This cookie is a Host Specific cookie that is set by each 11g Webgate when it is contacted or a request comes to it. Als this cookie is encrypted with a key that is specific to the WebGate that issued this cookie. (meaning you cannot replay this cookie at another WebGate.) If there are 3 applications being protected by OAM, then you will have 3 sets of webgates, each webgate protecting the particular application. So in this case you would have 3 OAMAuthnCookie, one per each Webgate.
 

ObSSOCookie: This cookie is only used in 10g webgates. So if you are in 11g or higher version 12c then you can safely ignore this cookie. This cookie is protected with secret keys only known to the OAM server. Since this 10g webages, only one global shared secret key is used for all of the 10g webgates installed in the OAM environment. It is a domain level cookie. Once again it is used in older version 10g and not used in 11g or 12c.

OAMRequestContext cookie: This cookie is only valid in 11g webgates and stores the original request details. This is a transient cookie set by 11g webgates.

OAM_REQ cookie: When OAM is configured in a cluster, i.e. there are two or more OAM engines in a HA mode then this cookie is used to store the authentication request context. This cookie stores the original request URL that was sent to the Protected resource.

DCCCtxCookie: This cookie is only used when OAM is configured in a DCC mode ie Detached Credential Collector. The DCCCtx Cookie is similar to OAM_REQ.


Above screenshots show OAM_ID and OAM_REQ cookie. And the below screenshot shows ObSSOCookie. These screenshots are from Firefox browser.




OAM Cookies for managing sessions and single sign-on
SSO Cookie Set at User LoginSet ByDescription
OAM_ID cookieOAM Server Embedded Credential CollectorWhen 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.
See Also: "OAM_ID cookie".
OAMAuthnCookie11g WebgateSet by each 11g Webgate that is contacted. Protected by the key known to the respective 11g Webgate and the OAM Server. A valid OAMAuthnCookie is required for a session.
Note: If the user accesses applications protected by different 11g Webgates, you will have multiple OAMAuthnCookies.
See "OAMAuthnCookie for 11g OAM Webgates".
ObSSOCookie10g WebgateA domain-based cookie for 10g Webgates is set only when a 10g Webgate is contacted. Protected with keys known to the OAM Server only. One global shared secret key for all Webgates.
Note: This cookie enables backward compatibility and inter-operability between Access Manager 11g and older agents.
See "ObSSOCookie for 10g Webgates"
OAM_REQOAM Server Embedded Credential CollectorA transient cookie that is set or cleared by the OAM Server if the Authentication request context cookie is enabled. Protected with keys known to the OAM Server only.
Note: This cookie is configured as a high availability option to store the state about user's original request to a protected resource while his credentials are collected and authentication performed.
See "OAM_REQ Cookie".
OAMRequestContext11g WebgateSet or cleared by the 11g Webgate and protected by the key known to the respective 11g Webgate and the OAM Server.
With Internet Explorer browser:
--When RequestContextCookieExpTime is not set, OAMRequestContext is a transient cookie.
--When RequestContextCookieExpTime is set, the OAMRequestContext cookie expires by the time set using the "Expires" directive. This requires a time sync between the client host and Web server host.
With all other (non-IE) browsers, when RequestContextCookieExpTime is not set OAMRequestContext expires in 5 minutes by default or by the time set using the "Max-Age" directive.
See Also: "OAMRequestContext"
Table 14-2, "User-Defined Webgate Parameters"
DCCCtxCookieDetached Credential CollectorFor detached credential collector (DCC)--similar to OAM_REQ created by embedded credential collector (ECC).
See "DCCCtxCookie"
OHS-host-portOracle HTTP ServerSet only when OSSO Agents (mod_osso) are contacted on Oracle HTTP Server (OHS). Protected with the key known to the respective mod_osso agent and the OAM Server.
Note: This cookie enables backward compatibility and inter-operability between Access Manager 11g and older agents.
See "mod_osso Cookies".
GITO cookieOAM ServerProvides backward compatibility and inter-operability between OSSO 10g and Access Manager 11g. The cookie is created by the OAM Server and accessed or modified by the OAM Server or mod_osso agent.
See "mod_osso Cookies".
OpenSSO cookieOpenSSO ProxySee "OpenSSO Cookie (iPlanetDirectoryPro)".
   

Related Posts

OAM Session and Cookies
Discussion on Oracle Identity Management forum on Multiple user credentials to access different resources
Understanding OAM SSO Cookies



Comments

Popular posts from this blog

VMware fix for Invalid manifest and ova file import failed errors

SOAPUI - import certificate

Centrally Managed Users (CMU) - New Feature in Oracle Database 18c