1

2
3
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
presentations.

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

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

Read the above conditions

5
6
There are 7 cookies we will see in the login/logout process:
OAMAuthnHintCookie
OAMRequestContext_
OAM_REQ_n
OAM_REQ_COUNT
OAM_LANG_PREF
OAM_ID
OAMAuthnCookie

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

7
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

8
Additional OAM cookie Information:

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

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

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

9
IV. OAM_LANG_PREF
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

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

11
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

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

13
Read the above steps …

14
What the end user sees …
Read the above steps …

15
Read the above steps …

16
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

17
Get = resource being called
Host = where it is located

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

Set-Cookie = OAMAuthnHintCookie, OAMRequestContext

R/R1
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.

19
20
Read the green

R/R2
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 …
login_page.css

What follows after this are requests and responses for the following:
http://oam11gr2ps3.vm.oracle.com:14100/oam/pages/css/general.css
http://oam11gr2ps3.vm.oracle.com:14100/oam/pages/js/config.js
http://oam11gr2ps3.vm.oracle.com:14100/oam/pages/js/loginJS.js
http://oam11gr2ps3.vm.oracle.com:14100/oam/pages/images/world_36x20.png
http://oam11gr2ps3.vm.oracle.com:14100/oam/pages/images/login_logo.pnghttp://oam11gr2ps3.vm.oracle.com
:14100/oam/pages/images/spacer.gif
http://oam11gr2ps3.vm.oracle.com:14100/oam/pages/js/messages.js
http://oam11gr2ps3.vm.oracle.com:14100/oam/pages/images/loginpage_bg.png
http://oam11gr2ps3.vm.oracle.com:14100/oam/pages/images/LoginContainer_bg.png

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

Css = style sheet

Js = java script

21
Post credentials
Enter usename password …enter

Note clear text un/pwd. unless SSL

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

R/R13

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

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.

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

24
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

25
Nothing special to see …

26
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

27
Nothing special

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

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

29
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

30
Read the above

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

32
Read the above

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

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

35
Read the green

36
Read the green

OAMAuthnCookie is expired

37
Nothing special

38
Nothing special

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

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

41
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
Servers".

42
43
-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 …

44
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
expired.
Oracle Fusion Middleware Administrator's Guide for Oracle Access Management, 23 Understanding Credential Collection an
https://docs.oracle.com/cd/E52734_01/oam/AIAAG/credcollect.htm#AIAAG89718

OAM 11g login

http://fusionsecurity.blogspot.com/2011/04/oam-11g-single-sign-on-and-oam-11g.html

OAM 11g logout

http://fusionsecurity.blogspot.com/2011/04/oam-11g-logout-part-one-of-two.html

46
MOS Community Q&A thread:

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

47
48
49
50