Oracle Access Management (OAM 11gR1)

# Oracle Access Manager 11gR1 provides a single authoritative source for all authentication and authorization services.
# Oracle Access Manager 11g provides single sign-on (SSO), authentication, authorization to registered agents (in any combination) protecting resources. Agents include:

* OAM 11g WebGates
* OAM 10g WebGates
* IDM Domain Agent
* OSSO Agents (10g mod_osso)



# OAM 11g can be integrated with any Web applications currently using Oracle ADF Security and the OPSS SSO Framework

More Here

Courtesy:http://www.gdbsinc.com/blog/

Oracle Access Manager (11g OAM) Request Flow

 

Oracle Access Manager Request Flow:

1. The user tries to access an application (resource) protected by Oracle Access Manager 11gR1 using his web browser.
2. The Oracle Access Manager agent  intercepts the request and tries to ascertain if the user has an authenticated session. Since this is the user’s first access, the user is redirected to the Oracle Access Manager 11gR1 Access Server for authentication.
3. Access Server’s credential collector component displays a Login Form as defined in authentication scheme. The user submits his credentials to the Access Server.
4. OAM validates the user’s credentials against user directory and generates a security token. The user is redirected to the resource he tried to access in Step 1.

Oracle Access Manager Session revalidate request flow:

1. The Oracle Access Manager agent intercepts the request and extracts the security token (cookie).
2. The Oracle Access Manager agent then makes a back channel call to the Access Server (OAP over TCP) to validate the session and authorize the request.
3. Oracle Access Manager authenticates the user from the LDAP repository.
4. Access server verifies the user’s permissions against the configured policy for the web resource.
5. Access server responds to the WebGate request indicating that access is allowed.
6. The Oracle Access Manager agent allows the request to go through.
7. The user is now able to access the web resource he tried to access in Step 1.

Posted in 11g IDM | Leave a comment

Oracle Access Manager 11gR1 Architecture

Posted on March 25, 2011 by kyadav

Oracle Access Manager 11gR1 architecture:

• User agents: These include web browsers, Java applications, and Web services applications. The user agents access the Access Server and the administration and configuration tools using HTTP.
• Protected resources: A protected resource is an application or web page to which access is restricted. Access to protected resources is controlled by WebGates or Custom Agents.
• Administration and configuration tools: Oracle Access Manager can be administered and configured by the Oracle Access Manager console, the Oracle Enterprise Manager Fusion Middleware Control and the Oracle Enterprise Manager Grid Control, and the WebLogic Scripting Tool (WLST).

More Here

Courtesy:http://www.gdbsinc.com/blog/

Enabling SSO for WebCenter 11g using Oracle Access Manager (OAM)

Configuring Single sign-on (SSO) between WebCenter components and/or other partner applications is an important part of WebCenter setup. OAM configuration with a WebCenter application is covered in detail in the WebCenter Admin Guide on OTN. Other solutions that can leveraged for SSO are SAML (“built-in” solution in WebLogic Server), Oracle SSO (OSSO), Windows Native Auth (WNA), etc. Each one has different setup requirements but the following few common “concepts” and functional points exist across the board.

Policy Decision Point (PDP): Point that evaluates and makes (authorization) decisions

Policy Enforcement Point (PEP): Point which intercepts a request and channels it to the PDP

Policy Administration Point (PAP): Points which help manage and administer policies

Identity Assertion Provider (IAP): A type of Authenticator that allows users or processes to assert their identity based on tokens (specific to the SSO solution)

The figure below shows where these functional points are. If you note, the Webgate, an out-of-the-box plugin that intercepts HTTP requests and forwards them to the Access Manager is the PEP and the Access Server the PDP. It also shows the sequence of the events in Single sign-on process.

More Here

Courtesy:http://mdevgan.wordpress.com/2011/01/09/enabling-sso-for-webcenter-11g-using-oracle-access-manager-oam/

Using Apache to simulate an SSL Load balancer

The numbers indicate the TCP port used on the server side. All of the red lines are HTTP. The green line (from OHS to the OAM Server) is the OAM NAP protocol.

1. SSLProxyEngine on

2.
3. Order deny,allow
4. Allow from all
5.

6.

7. RewriteEngine on

8. ProxyPreserveHost on

9.

10. NameVirtualHost *:443

11.

12.
13. ServerName login.oracledemo.com
14.
15. SSLEngine on
16. SSLProtocol all -SSLv2
17. SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
18. SSLCertificateFile /home/oracle/simpleCA/login.oracledemo.com.crt
19. SSLCertificateKeyFile /home/oracle/simpleCA/login.oracledemo.com.key
20.
21. ProxyPass / http://localhost:14100/
22. ProxyPassReverse / http://localhost:14100/
23.

24.

25.
26. ServerName idm11g.oracledemo.com
27.
28. SSLEngine on
29. SSLProtocol all -SSLv2
30. SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
31. SSLCertificateFile /home/oracle/simpleCA/idm11g.oracledemo.com.crt
32. SSLCertificateKeyFile /home/oracle/simpleCA/idm11g.oracledemo.com.key
33.
34. RequestHeader set IS_SSL ssl
35.
36. ProxyPass / http://localhost:7777/
37. ProxyPassReverse / http://localhost:7777/
38.

SSLProxyEngine on

Order deny,allow
Allow from all

RewriteEngine on

ProxyPreserveHost on

NameVirtualHost *:443

ServerName login.oracledemo.com

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /home/oracle/simpleCA/login.oracledemo.com.crt
SSLCertificateKeyFile /home/oracle/simpleCA/login.oracledemo.com.key

ProxyPass / http://localhost:14100/
ProxyPassReverse / http://localhost:14100/

ServerName idm11g.oracledemo.com

SSLEngine on
SSLProtocol all -SSLv2
SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW
SSLCertificateFile /home/oracle/simpleCA/idm11g.oracledemo.com.crt
SSLCertificateKeyFile /home/oracle/simpleCA/idm11g.oracledemo.com.key

RequestHeader set IS_SSL ssl

ProxyPass / http://localhost:7777/
ProxyPassReverse / http://localhost:7777/

There are a couple of interesting bits in that configuration...

First is that when you use mod_proxy Apache will use the host name in the URL specified in ProxyPass when it talks to the back end server. In this case that means that the OHS server would see a request with a host header that said "localhost:7777". Which can confuse the application and isn't at all what a conventional load balancer would do. Adding "ProxyPreserveHost on" to the configuration makes mod_proxy use the same name when it talks to the backend server (again OHS in my case) as the browser sent in the original request.

More Here

Courtesy:http://fusionsecurity.blogspot.com/2011/04/using-apache-to-simulate-ssl-load.html

OAM 11g session management

In OAM 10g and other products in the WAM space there is no actual tracking of a user's session. Usually in those products when a user logs in they are issued an encrypted cookie that tracks the login time, authentication level, the idle and maximum session times and a few other bits of information. If a user had such a cookie they were logged in, if they didn't they weren't. This sort of architecture was designed in a time when building massively scalable session tracking mechanisms wasn't really possible; in other words there was no way to build a million concurrent user SSO scheme deployed worldwide if you had to keep track of every active user session in a database or LDAP directory.
Times have changed.
OAM 11g takes advantage of a cool technology called Oracle Coherence. I'd tell you what Coherence does, but they do a pretty good job right there:

Coherence provides replicated and distributed (partitioned) data management and caching services on top of a reliable, highly scalable peer-to-peer clustering protocol. Coherence has no single points of failure; it automatically and transparently fails over and redistributes its clustered data management services when a server becomes inoperative or is disconnected from the network. When a new server is added, or when a failed server is restarted, it automatically joins the cluster and Coherence fails back services to it, transparently redistributing the cluster load. Coherence includes network-level fault tolerance features and transparent soft re-start capability to enable servers to self-heal

.

By plugging Coherence into the OAM architecture Oracle added the ability of the OAM Server to track all active users sessions without needing to go back to a massive central store (for example a database) and without needing to worry about building a replication strategy. Coherence hides all of that complexity and solves what is still a massive problem for some of our competitors. In the sequence diagram in my previous post I only drew the lines for HTTP traffic. I left out a bunch of stuff like the OAP communication from WebGate to OAM Server and the fact that the OAM Server will check that the session is active and legal before granting access. The more accurate, but still simplified, OAM architecture diagram looks more like this:

Each time the OAM WebGate talks to the OAM Server to ask "is the user authorized to see this resource?" the OAM Server checks the Coherence cache and will say "NO!" if the session has been deleted.
So if you want to terminate an user's session you can!

More Here

Courtesy:http://fusionsecurity.blogspot.com/2011/04/oam-11g-session-management.html

OAM 11g Single Sign-On and OAM 11g Cookies

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.


Plus if you're already familiar with OSSO or OAM 10g you probably already know what their cookies look like. So for the purposes of this post I'm only going talk about OAM 11g Server and the 11g WebGate cookies when you do an "HTML form" style login.
Basically if you want the contents Eric's post in pretty pictures and simplified down to include only the 11g cookies then this post is for you!
Here's a very simple diagram of the communication between the user, one OAM Server, one WebGate and one Application:

Note: In this diagram I've separated out the WebGate and the Application, though in reality the WebGate is plugged into the OHS Server and the app could be something as simple as a .CGI running in the same server. I've also shown the user talking directly to the OAM Server; in the real world this interaction would likely be through an OHS server with mod_wl installed.

More Here

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

Validating Authentication and Authorization in an Oracle Access Manager Application Domain

This tutorial elucidates the steps involve in several methods for confirming that Agent registration
and authentication and authorization policies are operational. The procedures are
nearly identical for both OAM Agents and OSSO Agents (mod_osso). However, OSSO
Agents use only the authentication policy and not the authorization policy.

Prerequisites

• Users and groups who are granted access must exist in the primary LDAP User Identity Store that is registered with OAM 11g
• Agents must be registered to operate with OAM 11g. After registration, protected resources should be accessible with proper authentication without restarting the Administration or Managed Server.
• Application domain, authentication policies, and authorization policies must be configured.

To verify authentication and access

1. Using a Web browser, enter the URL for an application protected by the registered Agent to confirm that the login page appears (proving that the authentication redirect URL was specified appropriately). For example: http://myWebserverHost.us.abc.com:8100/resource1.html
2. Confirm that you are redirected to the login page.
3. On the Sign In page, enter a valid username and password when asked, and click Sign In.
4. Confirm that you are redirected to the resource and proceed as follows:

More Here

Courtesy:http://oraclesoaandoim.blogspot.com/2011/02/validating-authentication-and.html

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.

More Here

Courtesy:http://oracleaccessmanagement.blogspot.com/2011/03/here-at-oracle-access-management-pm.html

Single Sign-on and the OBSSOCookie

The Oracle Access System implements single-domain and multi-domain single sign-on
through an encrypted cookie called the ObSSOCookie. The WebGate sends the
ObSSOCookie to the user’s browser upon successful authentication. This cookie can
then act as an authentication mechanism for other protected resources that require the same or a lower level of authentication.


When the user requests access to a browser or another resource, the request flows to
the Access Server. The user is logged in, and the ObSSOCookie is set. The Access
Server generates a session token with a URL that contains the ObSSOCookie. Single
sign-on works when the cookie is used for subsequent authorizations in lieu of
prompting the user to supply authorization credentials.


When the cookie is generated, part of the cookie is used as an encrypted session token.


The encrypted session token contains the following information:
- The distinguished name (DN) of the authenticated user.
- The level of the authentication scheme that authenticated the user.
- The IP address of the client to which the cookie was issued.
- The time the cookie was originally issued.
- The time the cookie was last updated.

If the user has not been idle, the cookie is updated at a fixed interval to prevent the session from timing out. The update interval is one-fourth of the length of the idle session timeout parameter.


Unencrypted ObSSOCookie data includes:
- Cookie expiry time.
- The domain in which the cookie is valid.
- An optional flag that determines if the cookie can only be sent using SSL.
Security of the ObSSOCookie


The ObSSOCookie is a secure mechanism for user authentication. When the Access
System generates the cookie, an MD-5 hash is taken of the session token. When the
ObSSOCookie is used to authenticate a user, the MD-5 hash is compared with the
original cookie contents to be sure no one has tampered with the cookie. MD-5 is a
one-way hash, so it cannot be unencrypted. The Access Server does the comparison by
hashing the session token again and comparing the output with the hash of the token
already present in the cookie. If the two hashes do not match, the cookie is corrupt.
The system relies on the fact that if someone tampers with the session token, the
hashes will not match.

More Here

Courtesy:http://securidm.wordpress.com/2009/07/13/single-sign-on-and-the-obssocookie/

Enabling SSO for WebCenter 11g using Oracle Access Manager (OAM)

Configuring Single sign-on (SSO) between WebCenter components and/or other partner applications is an important part of WebCenter setup.  OAM configuration with a WebCenter application is covered in detail in the WebCenter Admin Guide on OTN.  Other solutions that can leveraged for SSO are SAML (“built-in” solution in WebLogic Server), Oracle SSO (OSSO), Windows Native Auth (WNA), etc.   Each one has different setup requirements but the following few common “concepts” and functional points exist across the board.

Policy Decision Point (PDP):  Point that evaluates and makes (authorization) decisions

Policy Enforcement Point (PEP): Point which intercepts a request and channels it to the PDP

Policy Administration Point (PAP): Points which help manage and administer policies

Identity Assertion Provider (IAP): A type of Authenticator that allows users or processes to assert their identity based on tokens (specific to the SSO solution)
The figure below shows where these functional points are.  If you note, the Webgate, an out-of-the-box plugin that intercepts HTTP requests and forwards them to the Access Manager is the PEP and the Access Server the PDP.  It also shows the sequence of the events in Single sign-on process.

More Here

Courtesy:http://mdevgan.wordpress.com/2011/01/09/enabling-sso-for-webcenter-11g-using-oracle-access-manager-oam/