Password Policy in OAM 11g R2

One of the features in the new 11G R2 (or 11.1.2) release of Oracle Access Manager that's been most eagerly anticipated is the support for password policy within the OAM product; that is, the ability for OAM itself to support a subset of password management processes without the need to use Oracle Identity Manager and LDAP Sync. In this post, I'd like to explore this functionality in a little more detail and also explore exactly which use cases are supported.

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.

SAML is good, but it's no replacement for WAM

My recent posts about SAML got me thinking about a couple of common misconceptions I see from customers surrounding the technology.

The first and most important misconception is articulated by this quote:

"there is no SAML Fairy"

- Brian Eidelman

In other words there's nothing magical about SAML. Browsers don't "speak" SAML. SAML isn't like an HTTP cookie (and it's not like a chocolate chip one either, but I digress). SAML is just a means to convey identity from one place to another, so adding SAML into your architecture doesn't do anything to make it more secure. Application sessions will still be managed with cookies, hidden form fields, information in the query string or whatever it is that the app already did.

The other misconception / misunderstanding is that SAML can take care of all of your SSO problems. Or as a customer recently put it "if I just setup one authentication point for my enterprise and then use SAML to sign onto all of my applications I don't need a Web SSO solution like [OAM, OpenSSO, SiteMinder, etc]". This product space is usually called Web Access Management, abbreviated as WAM, which is pronounced like, but is unrelated to the band with a similar sounding name.

I've seen this same idea discussed by customers, application vendors and others so it seems pretty common. The fact the idea is common is bad, but it's the fact that it's both wrong and widespread that concerns me, and is why I'm writing this post.

The motivations people have put forward for using SAML in this way have included:

• using "the standard"
• only having thing to integrate to get SSO for everything
• lots of applications support SAML out of the box
• simplifying the environment
• loosely coupling infrastructure components

and of course...

• avoiding license costs

From a customer's perspective these are all valid desires and laudable goals. Unfortunately the reality is that SAML is simply not a replacement for a true web access management solution. The WAM space is one of those classic "elephant in the distance" problems - it's a whole lot bigger than you think it is when you start.

The main features of a WAM product (according to Wikipedia) are:

• Authentication Management
• Policy-based Authorization
• Audit & Reporting Services (optional)
• Single sign-on Convenience

Authentication Management includes obvious things like checking a username and password (i.e. HTTP Basic authentication or from an HTML form) or Certificates. It also includes features like requiring different authentication methods for different resources. The rest of the above are fairly self explanatory. I'd add a few more features that are common across most of the products in the space:

• Session management - including enforcing maximum session time, idle timeouts, administratively terminating a session, etc
• Security in depth - e.g. securing at least both the web tier and the app tier

If you use SAML for SSO you can centralize authentication, and if you do things carefully you can almost certainly get a limited form of Single Sign-On working. But trying to get most of the other items on my lists above is actually a whole lot harder than you might think.

Consider the use case where you have two applications protected with either a WAM solution or some sort of SAML integration. With a conventional WAM product you'd be able to log into either one and move back and forth seamlessly; your session would be active on either one or both apps for as long as specified in the central configuration and if you log out of one you would be logged out of all. Contrast this with the SAML solution...

You could do central login by configuring the existing login page of each application to kick off a Service Provider initiated SSO, and as long as your session was live at the central IdP you could go back there to get an assertion for the application. Of course you'd need to make sure that the central session didn't time out too early or you lose all SSO capabilities. You could also configure SAML to support Single Logout (SLO), though doing SLO across more than a handful of Service Providers gets problematic quickly.

So what are you missing? Lots of stuff...

• Authentication technologies. WAM products generally support a wide variety of authentication methods out of the box. From the common username and password, certificates, smart cards, SecurID and Kerberos to less common things like biometrics and multifactor methods. Enabling additional authentication method with a WAM product generally requires simply following a set of documented configuration steps. Contrast this with what most people think of as how they'll "do" a SAML IdP for their internal SSO project... a web app deployed on an app server. In that case you'll be able to support username and password, certificates, probably Kerberos and not much more very easily (for appropriate values of "very"). Further you start running into problems when you try to configure one web application to require more than one method - J2EE apps, for example, can only support one authentication method.
• Idle timeouts across the environment. Idle timeouts can't be enforced because SAML doesn't include a profile for session synchronization. Period. End of statement. Simply not possible with SAML. So once a user SSOs over to an SP there's no way to let the IdP know that the user is still actively using the app.
• Session time limits. Maximum session time limits generally can't be enforced because SAML only specifies a time period during which an assertion will be valid (NotBefore and NotOnOrAfter). The SAML specification does include another attribute (SessionNotOnOrAfter) which is supposed to specify the maximum session time the SP should allow. In my experience this support is generally poorly implemented in all but the most advanced SAML-supporting products. Anecdotally and FWIW I've gone to a number of interop test events and I've never actually seen this feature included in the conformance test suite. Caveat emptor!
• Central authorization policies. WAM products include "course grained access control" features. You generally wouldn't use a WAM product to secure individual features of an application, but using a WAM product to decide who is allowed to reach each application is common.
• Central Authorization Reporting. Centralizing policies means that you can easily figure out who is going to have access to each application. You can then use this information to generate useful things like attestation reports which are often required by security auditors.
• Central auditing. When a WAM product is deployed across applications you gain the ability report on who can do what (above) but also the ability to centrally track usage (who actually did what?). Most products will record user actions in flat files, a database, or both. Generating reports from that data then becomes a simple matter of pointing your reporting system at that data and clicking "Generate Report".

There are some other important features of WAM products, but those are the ones that come to mind immediately.

Then in addition to all of the features you're missing you introduce a bunch of additional problems. Such as? How about the fact that each Service Provider requires an x.509 certificate? And the fact that setting up a SAML Service Provider is still painful (even with the Metadata exchange protocol). And the fact that when you stand up a new SP you have to configure settings on the IdP.

None of which you have to worry about with a WAM product.

So when it comes to web browsers use SAML for the things it was intended to do - propagating identity across boundaries. And use WAM products for your intra-company SSO.

Do you disagree? Are you using SAML for your web SSO solution successfully? Have you figured out something I haven't?

Let me know below.

Integrating Oracle Access Manager with Kerberos authentication with fallback to an HTML form

Seems like it's the month of Kerberos.

We often see customers wanting authenticate users to Oracle Access Manager (OAM) with Kerberos, and fall back to HTML forms if the Kerberos authentication fails. There's an easy way to set this up, but it's not obvious how to do it.

I'm just going to describe the flow here, but that should be enough to help you figure out how to do the actual knob turning yourself. If you run into trouble feel free to ask a question here.

1. user accesses http://somemachine.mydomain.com/protected/
   
2. OAM redirects the user to http://trustedmachine.mydomain.com/oamauthenticator/
   
3. on trustedmachine the virtual directory /oamauthenticator/ is protected by IIS' built in Kerberos functionality, and only Kerberos. In other words you should uncheck the Basic, Digest and Anonymous checkboxes in the IIS console.
   If the user's workstation is in the domain and they are signed in then their identity will be passed to IIS via Kerberos. If the user's worksation is not in the domain or something goes wrong they will be presented with the 401 error page (see below)
   
4. the OAM WebGate will consume the identity from IIS and pass that identity to the Access Server
   
5. the OAM Access Server will search LDAP for the user
   
6. once the user's OAM session has been established they will be redirected back to http://somemachine.mydomain.com/protected/ along with the ObSSO cookie.
   

alternative flow for workstations not in a domain or if Kerberos fails:
In step 3 if the Kerberos authentication fails IIS will send the HTML file configured as the 401 page

You can create a plain HTML page that

• contains a conventional OAM login form - prompting the user for their username and password.
  
• submits to an URL on trustedmachine
  
• that URL will be associated with a conventional OAM HTML forms login authentication scheme
  

When the user fills in the form and hits submit:

1. the credentials will be passed to the Access Server
   
2. the Access Server will search LDAP for the user and bind to the directory to authenticate them
   
3. if the credentials are correct the user will get an OAM session cookie
   
4. the user will be redirected back to the original resource as in the normal flow above.
   

The only real trick here is using the custom error page in IIS. Remember that you have to use a plain HTML file for that file - you can't use an ASP/ASPX. That also means that you have to do anything dynamic in JavaScript.

Update: I fleshed this out some more in a newer post.

Protecting OAM (IdentityXML) with OSB

A great use case for this blog - "How to add OSB in front of OAM". This question came from a customer, and touches on a number of interesting issues

This link has all of the information about the WSDL for Identity.xml.


This link describes how to use WSDL in OSB


To clarify, you can load the WSDL as a file into OSB and use those local WSDLs to work with the services of IdentityXML. The fact that OAM does not expose the WSDL in the ?WSDL form is not an issue. OSB is happy to work with a file.

So, basically:

1 - Create a proxy service for a WSDL ( this will expose ?WSDL to clients)
2 - Create a business service for an Identity XML using the same WSDL
3 - Create a pipeline that maps that routes the requests (very simple mapping...not much work)

The most interesting part here is how to propagate the credentials through OSB.

IdentityXML uses a proprietary format - It doesn't use WS-Security. IdentityXML looks for all of the information in the body, but I would argue a "better" implementation and a better use of OSB would be to add more standard WS-Security tokens to the exposed WSDL.

For example, you could replace the username/password elements with WS-Security UsernameTokenProfile and the ObSSOToken could be mapped to a custom WS-Security BinaryToken (common) practice.

To this, you wouldn't process the WS-Security Envelope in OSB, but rather do some transformations from the exposed WSDL and WS-Security messages to their appropriate localtion inside of the actual IdentityXML endpoint running in OAM.