Vous êtes sur la page 1sur 50


This presentation will provide a basic understadning of the OAM 11g login and log out process for a
known good request using an Embedded Credential Collector, which will be used as foudation for future

There are many differant varibles thatn can effect the flow durring log and logout.

Some example are ... the ECC, the DCC, load blancing, authn schemes, cusotm pages, the list goes on and

This presentation used the following conditions for testing and the resulting data for this presentation.

Read the above conditions

There are 7 cookies we will see in the login/logout process:

The 2 cookies that are the most useful for login/logout issues are the statuses of the OAM_ID and the
OAMAuthnCookie cookies

The OAM_ID is an encrypted (keys known to the OAM Server only) server scoped single sign-on cookie
that is generated by the Access Server on successful login.

The contents of this cookie are:

Session identifier (referenced to server side session)
Key identifier (reference to cookie encryption key)
Cookie version
Random salt - In cryptography, a salt is random data that is used as an additional input to a one-way
function that hashes a password or passphrase. The primary function of salts is to defend against
dictionary attacks versus a list of password hashes and against pre-computed rainbow table attacks.
Integrity hash

The OAMAuthnCookie … OAMAuthnCookie_<host:port> is an encrypted server scoped single sign-on
cookie that is generated by the Access Server and set by 11g Webgate on successful login. (Protected by
the key known to the respective 11g Webgate and the OAM Server.)
A valid OAMAuthnCookie is required for a session. If the user accesses applications protected by
different 11g Webgates, you will have multiple OAMAuthnCookies.

The contents of this 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

Additional OAM cookie Information:

I. OAMAuthnHintCookie
A domain scoped cookie that has a boolean value: either "1" or "0"

value "1" serves as a hint to the WebGate for redirecting to the OAM Server over the front channel to obtain the token for OAMAuthn cookie.
value "0" or the absence of the OAMAuthnHint cookie would be a hint that the user has not been authenticated yet.

II. OAMRequestContext_
A transient cookie that is set or cleared by the 11g Webgate. Protected by the key known to the respective 11g Webgate and the OAM Server.
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.

III. OAM_REQ_n cookie and OAM_REQ_COUNT ..use to be OAM_REQ_

Use to be the OAM_REQ cookie.
This is s an encrypted server scoped session cookie that is generated by the Access Server prior to credential challenge.
It contains server state that is needed to continue processing post credential submission in highly available deployments.

-URL of the requester protected resource
-Agent identifier
-Number of authentication attempts
-Authentication policy identifier
-List of processed event identifiers in this request

Further Information
- It is only generated when the Request Cache type in the OAM configuration is set to COOKIE.
- It can be broken into multiple cookies if it exceeds the size defined in the oam-config.xml... parameter "serverRequestCacheSize" default value 3000 (3k).
- Each cookie that is created is represented by oam_req_0, oam_req_1, etc
-The number of cookies created is tracked by oam_req_count

The language preference cookie, OAM_LANG_PREF is a domain scoped cookie
In the following slides, there are a total of 15 steps, 2 Screen captures, and 17 http headers request/response.

1. Pre login presented

Steps 1-5, Screen Captures 1, R/R 1-12

2. Post login presented

Steps 6-15, Screen Captures 2- 3, R/R 13-17

This diagram is from the OAM documentation set.

It shows the processes involved in evaluating policies, validating a user's identity, authorizing the user for
a protected resource, and serving the protected resource.

There are a total of 15 steps, which we will see in the next 3 slides, that describe the basic flow.

Think of the overall login process as two groups, Pre credentials and Post credentials

Pre credentials are Steps 1 -5, which start with call of resource and end with the login page being presented

Read the above steps …

Login presented
Steps 1-5, Screen Captures 1, HTTP Header R/R 1-12

Post credentials - Steps 6 through 15, starts with providing user credentials and ends with the requested resource
being displayed.

Read the above steps …

Post credentials
Steps 6-15, Screen Captures 2- 3, R/R 13-17

Read the above steps …

What the end user sees …
Read the above steps …

Read the above steps …

Read the above steps …

We have showed the flow via Diagram, then broke that down to the 15 steps, then end user experience… next we
will take a look at the http header trace.

Each call consist of a request (From Browser) and a response (http listener type server like Webserver/WG or the
OAM server)

The format I will use to show the http header trace will be to first show the request, point out anything we should
be observing (if any), than the same for the response, than a summary

Cookies are always set in response

Location ???

See the requeste and the hsot it went too

Get = resource being called
Host = where it is located

HTTP/1.1 302 Found (note this is a redirect) - Location = tells were the response is from … (obrareq.cgi is OAM

Set-Cookie = OAMAuthnHintCookie, OAMRequestContext

When the user first attempts to access a protected resource the WebGate will detect that the resource is
protected and that the user needs to be redirected to the OAM Server to login. The WebGate stores some
information about the user's request, generates a cookie as a key to this context and sends an HTTP response with
this cookie and the URL of the OAM Server.

Read the green

The browser then follows the redirect and loads obrareq.cgi from the OAM Server. Loading the page …there may
be additional components that need to be loaded like style sheets, images, excreta.
R/R2 to R/R12 shows this. I have only included the header from the first object the loign page calls …

What follows after this are requests and responses for the following:

After the loign page is done loading its objects … the end user is presented with a login.

Css = style sheet

Js = java script

Post credentials
Enter usename password …enter

Note clear text un/pwd. unless SSL

Read the green
Notice location and the OAM-ID cookies is set


The user enters the username and password and hits the Login button. The browser does an HTTP POST to

The OAM Server validates the username and password. Since they're correct it generates an OAM_ID cookie. This
is the first cookie we've seen so far that identifies the user. If you look carefully you'll notice a couple of interesting
things about the cookie: The first is that it doesn't have a domain= setting; as a result the OAM_ID cookie will only
be sent by the browser to the OAM Server; no WebGates will ever see the OAM_ID cookie. The second interesting
thing to notice is that the cookie is marked "HttpOnly"; the HttpOnly marker tells the browser that the cookie
should NOT be accessible to Javascript or browser plug-ins.

The OAM Server redirects the user back to obrar.cgi (this time on the application) with encreply= and a big long
encrypted string. The encreply that the OAM Server includes in that redirect contains enough information to allow
the WebGate to pick up the user's session from the OAM Server.

Read the green
Request 14 (note obrar.cgi is on the webgate)

Read the green

Note OAMRequestContext_oam11gr2ps3 set to expired

The webgate session cookies is set...OAMRequestContext_oam11gr2ps3.vm.oracle.com:7778_)

This is the second cookie we've seen that identifies the user. Again, this cookie is host-specific and HttpOnly.

The user follows the redirect back to the original resource

Nothing special to see …

http://oam11gr2ps3.vm.oracle.com:7778/favicon.ico (note is seen when logo is present in browser address bar)
not from OAM nothing we can do …will need to check with browser vender

Nothing special

The user follows the redirect back to the original resource

Resource is displayed

Summary of the flow… from the Diagram, steps 1-15

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.

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

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 the following slides, there are a total of 3 steps, 2 Screen captures, and 4 http headers request/response.

1. Logout process ...

Steps 16-18, Screen Captures 4-5, R/R 18-21

Read the above

In our case the logout link is coded to call … http://oam11gr2ps3.vm.oracle.com:14100/oam/server/logout

Read the above

Select logout link ... http://oam11gr2ps3.vm.oracle.com:14100/oam/server/logout

Read the green
You can see that the HTTP response contains a Set-Cookie to expire the OAM_ID cookie.

Read the green

Read the green

OAMAuthnCookie is expired

Nothing special

Nothing special

Calls the /oam/pages/logout.jsp on the OAM server

Summary of logout …

The OAM server tells the browser to expire any of the OAMAuthnCookies which individual WebGates may have
issued using a HTML and Javascript in the page that the OAM server serves up when you start a logout. When
/oam/server/logout is first loaded a clock animated gif spins, while the OAM server is telling your browser to load
an image from each WebGate. When that image is loaded the WebGate deletes your cookie. The image file itself is
a checkbox, but you never actually see it because the height and width are zero pixels. When the picture finishes
loading the JavaScript onload event fires and a counter is incremented. When the counter reaches the expected
number of images (again one per WebGate that has issued you a cookie) the JavaScript function sends you on your
way to the default final page - /oam/pages/logout.jsp. The actual URL of the hidden image is a configurable value
called the Logout Callback URL. By default OAM Server will construct the URL for the hidden image as http:// or
https:// followed by the DNS name it redirected the user to when they logged on, followed by the string in the
Web Agent's Logout Callback URL setting, which defaults to "/oam_logout_success". You can change this behavior
by putting a different string in the setting (I prefer /oam_logout_callback). If you find that the OAM Server is using
the wrong hostname for the redirect you can provide an entire URL - just enter the entire URL beginning with http
or https in the field.

From the request of the resource, to the presentation of the login, to entering and validating of the
credentials, the 11g and 10g webgate are the same.

The first real difference between OAM 11g and OAM 10g WebGates behavior is when the browser does a
GET /obrar.cgi .... With the 10g WebGate we see ObSSOCookie instead of a 11g’s uniquely named cookie
OAMAuthnCookie_<host:port>_<random .

In both cases, the contents of the cookies are the same

These cookies are updated periodically using an algorithm of 1/4 of idle session timeout.

The standard 10g WebGate configuration parameter used to trigger initial logout through a customized
local logout page as described in "Configuring Centralized Logout for 10g WebGate with 11g OAM

-Get header trace to confirm what cookies are set and what cookies are not. The
information returned will vary depending on the Tool used …IE headers, FF Live http
headers, Fiddler, etc…
-Try to use the information of this basic login/logut to break it into steps. Confirm
what has workd and what has not.
- To test the login page in regards is accessible …no functionality.
- To test the logout page in regards is accessible … this will perform logout
-Access tester …

Once you have completed a successful login you will have supplied a resource that is protected, and a valid
username and password, resulting in the called resource being delivered.
Both OAM_ID and OAMAuthnCookie are set.

A successful logout has occurred when invoking /oam/server/logout. Both OAM_ID and OAMAuthnCookie are
Oracle Fusion Middleware Administrator's Guide for Oracle Access Management, 23 Understanding Credential Collection an

OAM 11g login


OAM 11g logout


MOS Community Q&A thread:

Advisor Webcast - OAM 11g - OOB Basics for the ECC -Q&A