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