OAM 11g Authentication as a Webservice

A bit advanced topic for those who want to dive deep into OAM..

Check out other good blogs from Eric and Chris to understand the nitty gritty of how SSO works

A common scenario for an access manager to fulfill authn/authz services is for a client to pass the necessary credentials to an agent and the agent in turn will pass the info to OAM via the http/OAP protocols. The agents used here are ofcourse the webgates and the accessgate. The webgate being specific to the webservers and the accessgate being the customized agent for the client application that may or may not have a webserver.
Now what happens if you are in a situation if the client does not have a webserver that oracle agents normally are compatible with. The client is left alone to use the accessgate that may involve lots of customization or he may just not use access manager as his solution.

What if there's a way if you could remove the clients webserver dependency on webgate/accessgate and yet provide a standard way of communicating to Oracle Access Manager.
The solution is using OAM as a webservice and yet the necessary mechanics for a successful OAM authentication still remains unchanged. In other words the agent(accessgate) is moved to the back-end probably remaining in the same box as the OAM or another box.

So what exactly drives the OAM authentication to trigger. The following diagram depicts the above scenario.

The request for a resource can be done in two ways

From a web client such as a browser




Or from a standalone client such as a java application



Note in both the above cases the client does not require any webgates/accessgate

Before I jump into the details of the above some of the soap features worth mentioning (of which some of you may be already aware of ) are
Soap

1. Uses standard internet HTTP
2. Uses XML to send and receive messages
3. Platform independent
4. Language independent
5. A protocol for exchanging information in a decentralized and distributed environment
6. Soap happens to be one of the key features of Microsoft's .Net Architecture especially, Web Services

Web services describes a standardized way of integrating Web-based applications using the XML, SOAP, WSDL and UDDI open standards over an Internet protocol backbone. XML is used to tag the data, SOAP is used to transfer the data, WSDL is used for describing the services available and UDDI is used for listing what services are available. Used primarily as a means for businesses to communicate with each other and with clients, Web services allow organisations to communicate data without intimate knowledge of each other's IT systems behind the firewall


Flow in a nut shell

1. The client requests for a resource.
2. The request is submitted to a proxy client which in turn makes a soap call to OAMAuthService which is a webservice.
3. This service calls the OAM 10g ASDK API.
4. The ASDK API invokes the accessgate (which is installed) to communicate to the OAM server .
5. The OAM server performs authentication and passes an encrypted token back to the client.

Components

The components involved in the above architecture are

OAMServer: The emphasis here will be a OAM 11g server . That provides the authentication service

AccessGate: AccessGate is the building block for all webgates. Unlike webgates where it is always associated to a webserver an accessgate is used by standalone application or by a non web applications. say for eg a java program or an EJB or and C program etc. Accessgates are the only way to communicate with the OAM server

OAMAuthService: A java file that consists of the implementation APIs for the webservice. These API call the AccessGate ASDK API which communicate with the accessgate and in turn talks to the OAM server for authentication check

WebServiceClientProxy: This is a Java proxy that is used to make webservice calls on OAMAuthService All web and non web applications will instantiate this java class for OAM Auth Services

OAMAuthServlet: This is a sample servlet file that instantiates the WebServiceClientProxy and also collects the username and password and submits them to the OAM Server via the WebServiceClient Proxy


Scope
The scope is limited to sesssion token validation between similar agents. i.e the token obtained from one 10g agent can be used with another 10g agent. The 10g token cannot be used with a 11g agent. This is limited in the current release.

Sample Code
https://www.samplecode.oracle.com/tracker/tracking/linkid/prpl1004?id=S757

The sample code folder also consists of a Jdeveloper IDE project file. (Helpful for those who would like to view and deploy from an IDE)

I hope you have enjoyed this article and leave comments if any.

OAM 11g deployment with a multi-million user population live!

The first production deployment of OAM 11g with a multi-million user population is now live! Starting April 1st, 2011, OAM 11g is now taking 100% of authentication load from extranet web properties of Oracle. All customers that access any Oracle service over the extranet are now authenticated with Oracle Access Manager 11g.

All web authentication traffic at Oracle; intranet or extranet; desktop or iphones; end-user or programmatic, is now being handled by OAM-11g system. Collectively, this amounts to about 750 K authentications requests on a typical working day. As we transition more systems to use Corporate SSO we expect this number to grow in the coming quarters.

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.

3) 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 this step if you are using an OAM 10g webgate, the response from the server will contain the information required to set ObSSOCookie, if you are using mod_osso, the response will contain the information required to set the OHS host cookie.)

4) When subsequent requests are made from that Webgate, the authentication token is passed by the Webgate to the OAM server, which validates the authentication token, checks the validity of the OAM_ID cookie and session timeout, and does the appropriate authorization checks. As the result of authorization checks, additional attributes may be added to HTTP Headers and passed to downstream applications. This is especially useful when asserting user identity and group or role information to downstream applications such as those running on Oracle WebLogic Server and Oracle Fusion Middleware.

5) When requesting a resource protected by a second Webgate, the request flow will be similar to the above. Webgate2 will check if the resource is protected, and get the authn scheme details from the OAM server. From there WG2 redirects to the OAM server, the OAM server checks the OAM_ID cookie, and then generates a new authentication token for WG2, creates an encrypted response using the key for WG2, and redirects to WG2. WG2 decrypts the response, extracts the authentication token and session identifiers and sets an OAMAuthnCookie as a host cookie for WG2.

New OAM 10.1.4.2 Certifications Released (June 2009)

The following new OAM 10.1.4.2 Certifications have been released:
1) Oracle HTTP Server (OHS) 10.1.3.4+ v2.0 (64-bit) WebGate for HP-UX Itanium 11.23 and 11.31
2) Lotus Domino Web Server 8.5.x (64-bit) WebGate for Windows 2003 EE SP2+ and Windows 2008 EE - x86-64 hardware
3) Sun Java Webserver 7.0.x (64-bit) WebGate for Solaris 10 (64-bit) - SPARC S2 hardware

Additional Resources:
OTN (download) location
OAM 10.1.4.x Support matrix location
OAM 10.1.4.x Package list location

SOA Security - ADT or Crocodile Filled Moat?

I'm sitting here in the middle of the Moscone center as OpenWorld 2008 comes to an end. It's been a long week, but I wanted to take some time to capture some thoughts on my first open world presentation.

This morning, Eric Leach and I presented to an enthusiastic group on securing WebLogic applications with Oracle Access Management. As the "technical guy", I put together a demo of Oracle Access Manager, Web Logic Server, Oracle Entitlements Server and Oracle Web Services Manager all working together in a "best practice" architecture.

The demo covered a fairly common scenario: end-to-end security in a SOA. For example, the customer already has an investment in OAM, and they need to extend that security capabilities down to the rest of the architecture - applications, services and data.

In the past, I think that the temptation would be to use OAM. Prior to the emergence of the entitlements market, WAM was the only COTS solution for externalizing authorization. WAM products are most successfully deployed when focused on the problem of web SSO. Authorization and the centralized management of security policy is better handled by Oracle Entitlements Server - OES.

I used OES to provide authorization for JEE resources, JSP pages, and Web Services. Both OES and OAM used a common directory - Oracle Internet Directory - as a system of record for users, user attributes and group memberships. This information fed the policies enforced by OES.

In order to have these policies enforced correctly, the various enforcement points need to have the correct user identity. The problem of propagating identity across an SOA is not a simple one. In the course of the demo, I actually had to use multiple mechanisms. The identity from OAM to WLS is passed via OAM Session cookie. WLS then generates a SAML Assertion and passes it in the WS-Security Envelope to a OWSM. OWSM in making the very fine grained access control checks to OES uses a simple USERID_TOKEN (username). In theory, I could have used SAML for all of these interactions, but in many cases the full on SAML is too much.

Like most everything in security, there is no "correct" answer - no perfect solution. The solution that I demonstrated using OAM, WLS, OES and OWSM is an attempt at a reasonable 80% case - something which most customers could use as a jumping off point for defining their own solution.
I think a good analogy in information security to "How much security is enough security?" is "What alarm system should I buy for my house?". I like to think of the solution I outlined in the OOW session as the "ADT Starter Package" of solutions - pretty good for most single family residences. Most houses don't need a moat or guard dogs, but a military base needs more than a "Keep Out" sign...you get my point :)

Thanks again to everyone who attended the session and all of the questions. I gave out quite a few business cards, so I hope to hear from all of you. For those who didn't attend, once I get home, I'll add the relevant links form the session, and hope to drive some discussion around the solution.

Where have all the PEP's gone?

I've been having a lot of conversations which customers lately around integrating security services - mostly authentication and authorization - into their enterprise. They've been asking basically the same question - "Where are the Policy Enforcement Points (PEP)?"

First of all, I think this is more than a simple product road map question. For the record - Oracle Access Manager (OAM) supports a large number of Web Server/Operating System platforms. Oracle Entitlement Server (OES) has a Security Module (SM) for a number of Web Servers, WLS + layered products, IBM WebSphere, Oracle VPD support and even Microsoft SharePoint.

Product Management can correct me, but this seems like a pretty good list. So what is the issue?

I think the issue is that many of the customers that I talk to are using a number of application frameworks to build their applications (Struts, JSF, Spring, Hibernate, ADF etc). This means that they want an application framework specific PEP and not a generic Java, JACC, JEE or even Application Server specific PEP. Even though these frameworks are built on these standards, implementing a policy enforcement point at those levels means that the access control policies are going to be based on resources like Java Permissions, Java Servlets or Enterprise JavaBeans. If the goal is to author access control policies which are closely aligned to the business, then securing these lower level resources, especially in the context of an application framework, is practically a non-starter.

So, why not just create PEPs for these application frameworks?

Easier said than done! Not every application framework has a tidy way of wedging an external PEP into the request flow, or reusing the application framework's PEP to call out to a 3rd party PDP. In most cases, externalizing authentication is pretty straight forward, but if you want 3rd party authorization, especially around framework specific objects (Struts Action, JSF UIComponent etc), it will get messy!

Oracle's Application Developer Framework (ADF) and Spring with SpringSecurity (ACEGI) both have the ability to externalize authorization built in, though ADF is based on standard Java security and ACEGI isn't.

In other cases, where there's a will, there's a way. I've pulled together a catalog of some approaches for integrating into various containers. Take a look. I've used these types approaches in the field to integrate various PDPs.

So, what do you think?

- Is dependency injection (aspect oriented) a reasonable way to add this type of fine grained authorization?
- For Struts, is creating a custom RequestProcessor a workable solution? It would allow for authorization at the Struts Action level.
-Is there something short of a custom Render Kit which would meet the requirements for JSF?
-Is a generic approach like JSP tag libraries best?

How To: Setting up Oracle Access Manger for Multiple Authentication Types

David Abramowicz, a Senior Sales Consultant for Oracle in Sweden, put together a how to for setting up OAM with multiple authentication types while maintaining the originally requested URL.

Thanks David!

Background

Frequently customers want their users to choose between multiple different authentication types, but still be redirected back to the originally requested URL after authentication. This requires setting up an authentication scheme to broker authentication mechanisms, and some redirect manipulation as described in this document.

Basically a forms based authentication is set up, which is a list of URLs protected with different authentication mechanisms. After a user selects one of the URLs, that particular authentication is executed. The user is then redirected back to the originally requested URL.


In order to set this up, you need to execute the following steps:

• Set up new authentication mechanism: “Authentication Selection”
• Set up redirection script on action URL of “Authentication Selection”
• Make a list of Authentication URLs for choosing “Authentication Selection”
• Create a policy domain for Authentication URLs

End-User Flow

1. User accesses URL protected with “Authentication Selection”
2. User gets redirected to “Authentication Selection” form URL
3. User chooses between authentication mechanisms
4. User authenticates successfully
5. User gets redirected to action URL of “Authentication Selection”
6. User gets redirected to originally requested URL


Set up new authentication mechanism: “Authentication Selection”

• Create a “Form” authentication mechansism, call it “Authentication Selection Level 1”
• Make sure that the mechanism has passthrough:yes, to have access to originally requested URL

It is important to ensure that users can’t actually authenticate using this mechanism, as seen below in the credential_mapping:

Set up redirection script on action URL of “Authentication Selection”

On the action URL of “Authentication Selection”, redirect to originally requested URL by parsing the obFormLoginCookie:

<--code snippet for parsing obFormLoginCookie-->

<%@ page import="java.util.*" %>
<%

//Get Redirect URL from ObFormLoginCookie, and redirect
Cookie[] cookies = request.getCookies();
String cookieValue = null;
for(int i = 0; i < cookies.length; i++) {
if (cookies[i].getName().equalsIgnoreCase("ObFormLoginCookie")) {
cookieValue = cookies[i].getValue();
break;
}
}

cookieValue = java.net.URLDecoder.decode(cookieValue);

String relativeURL = null, host = null, redirectURL = null;

StringTokenizer tokenizer = new StringTokenizer(cookieValue);
relativeURL = tokenizer.nextToken();
relativeURL = tokenizer.nextToken();
relativeURL = relativeURL.substring(relativeURL.indexOf("=") + 1);

host = tokenizer.nextToken();
host = tokenizer.nextToken();
host = host.substring(host.indexOf("=") + 1);

redirectURL = host + relativeURL;
response.sendRedirect(redirectURL);

%>

<--code snippet-->

Make a list of Authentication URLs for choosing “Authentication Selection”

• Create a web page with a list of two or more authentication mechanisms.

• Every list item should point to a web page that redirects to the action URL of “Authentication Selection”
  <%response.sendRedirect("redirect.jsp");%>

• Please make sure you don’t use the same action URL for “Authentication Selection” as for any of the real forms-based authentication mechanisms, as this could overwrite the obFormLoginCookie OAM uses for redirection

Create a policy domain for Authentication URLs

• Create a policy domain that protects this list.

• The authorization rule for all URLs in the list should be “Allow all”
• For each authentication mechanism in the URL list, create a policy domain

• The authentication rules needs to be set up for each URL/policy, where every URL/policy is protected with the appropriate authentication mechanism

That's it! You should be all set to go. You can also set this up to work with multiple authentication levels.


Authentication Selection with Levels

• Create another “Form” based authentication as above called “Authentication Selection Level 2”,
• Point the form URL to a new list of authentication mechanisms, where all mechanisms match authentication level 2.

New OAM Webgates Released

I am pleased to announce the release of 4 new OAM 10.1.4.2.0 webgates.

• Microsoft Windows 64-bit native ISAPI Webgate
• RHEL 4/5 NPTL enabled 64-bit native Apache 2.2 Webgate
• HPUX 11.23 NSAPI Webgate
• HPUX 11.23 OHS v1.3 Webgate

All the webgates can be found on Oracle's OTN download site here:
http://www.oracle.com/technology/software/products/ias/htdocs/101401.html

Where to Download OAM Components

Many Oracle Access Manager customers have asked "Where do I download the latest OAM patchset?" or more specifically "Where do I download the webgate for insert webserver name and version running as a insert 32-bit or 64-bit application on insert OS platform name and version ?"

Due to the many possible download locations, there is no simple answer to any such questions. Hence, I decided to post a guide to finding all OAM 10.1.4.x component packages.

OAM 10.1.4.0.1 base installers can be downloaded here:
http://www.oracle.com/technology/software/products/ias/htdocs/101401.html

• In the row marked "Oracle Access Manager".

OAM 10.1.4.2.0 patchset (latest version as of this post) can be downloaded here:
Metalink Patch Number 5957301

• Make sure to select the appropriate platform.

Index of all OAM 10.1.4.x 3rd Party Packages including webgates and connectors is here:
http://www.oracle.com/technology/products/id_mgmt/coreid_acc/index.html

• At the bottom of the page labeled as "Index of Released Oracle Access Manager 10.1.4 3rd Party Packages (PDF)" or use this direct link here.
• The index lists all the package names and download locations of all OAM 10.1.4.x 3rd party packages. The last column labeled as "Link" states the download locations.
• If the download location indicates something like IBM CD2 or Linux CD1, please go to the following link http://www.oracle.com/technology/software/products/ias/htdocs/101401.html and look in the row "Oracle Access Manager - 3rd Party Integration".
• If the download location indicates "Oracle Access Manager CDs", then the package is bundled with the OAM 10.1.4.0.1 base installers. Download location for the base installers is listed above.
• If the download location indicates Patch , please log into Oracle's metalink here https://metalink.oracle.com. In the Quick Find section choose "Patch Number" and enter the patch number as indicated in the index PDF.
• Please note that the index will be updated regularly as new packages are released.

I hope this is helpful for everyone. Please look forward to more helpful OAM tips and tricks in the near future.