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.

Firstly, though, let's have a brief history lesson....

Password policy in previous OAM versions

Long-time OAM users will know that the 10g version of the product included a fair bit of functionality that allowed direct management of user profile information (and hence quite complex self-service password management) in the underlying LDAP directory. This was achieved by the combination of a number of components, but essentially relied on a number of custom attributes that were added to the LDAP schema (the so-called "ob* attributes") when the OAM 10g Identity Server was installed. Authentication plugins would check the values of these attributes at login time and if necessary, would automatically redirect the user to appropriate WebPass URL's if a triggering condition were encountered. An example of this would be the obPasswordChangeFlag attribute which, if set to true for a particular user, would prompt OAM 10g to redirect that user to a password change URL on successful authentication.

The first release of OAM 11g moved away from that model completely, re-positioning OAM as a product that did access only, never identity. The assumption was that some other process would take responsibility for ensuring that the correct information ended up in the underlying LDAP user store and hence no functionality was included within OAM 11gR1  to perform any meaningful manipulation of LDAP user data, much less expose this to users for self-service purposes. Password policy was left up to the underlying LDAP directory to implement, with OAM respecting the authentication decision made by the LDAP server; for instance, if a user's password had expired then OAM would refuse to allow login, since the back-end LDAP bind for that user would fail. While this approach of "letting the directory decide" may have been OK from a security point of view (that is, it was possible to expire passwords, lock out users and so forth) it fell down from a usability perspective. In short, there was no way to meaningfully let the user know:
1) why their authentication had failed, or
2) what action they needed to take to enable access, such as resetting their password or calling a helpdesk to unlock their account.

Moreover, there was no facility provided for automatically redirecting users to the appropriate self-service page to perform the necessary action.

OAM integrated with OIM in 11gR1

The answer within the 11g R1 suite of products was to integrate OAM with OIM (Oracle Identity Manager) to enable self-service password management flows. We won't go into this set-up in too much detail here, save to mention the following highlights:
- it is enabled by OIM's LDAP Sync capability, which uses a combination of event handlers and scheduled tasks to synchronise the OIM user repository (database) with the LDAP server used by OAM
- it involves extending the LDAP schema to support a similar set of custom attributes for managing password state. LDAP Sync is responsible for setting these attributes when changes are made to the user profile in OIM. An example is to set the obPasswordChangeFlag to true when the "user must change password at next login" checkbox is checked in OIM.
- it enables OAM to redirect users to appropriate OIM self-service pages when a corresponding trigger event is detected, thus mimicking the functionality available in OAM 10g, with OIM taking the place of the no-longer-available WebPass component.

While the integrated OAM-OIM solution was functionally complete, there was still demand for a stand-alone password management solution utilising OAM alone.

Password policy in OAM 11g R2

Moving forward to the present day (December 2012, for the record) we find that the 11g R2 (11.1.2) release of OAM again includes some level of password policy, or user password self-service capability, within the Access product itself, allowing customers to provide a subset of these processes without needing to integrate OAM with OIM (or anything else). The rest of this post will explore exactly what is (and isn't) possible.

Let's start by looking at the configuration page that we use to define global password policy in OAM 11g R2. At this point, I'll shamelessly link to an image straight out of the product docs:

As you can tell from the image, the majority of the options relate to password complexity, which should be relatively easy to understand. What is perhaps more exciting is not the fact that OAM can apply complexity rules to password changes; it's the fact that OAM now ships with the capability to capture password changes in the first place!

It's interesting (and perhaps not all that surprising) to note that that 11gR2's password policy is once again dependant on schema extensions to the underlying directory, with the product shipping schema extension files for the following directories:

• Oracle Internet Directory
• Oracle Unified Directory
• Oracle Directory Server, Enterprise Edition
• Oracle Virtual Directory
• Microsoft Active Directory
• iPlanet (Sun Java System) Directory
• Novell eDirectory
• OpenLDAP
• IBM Tivoli Directory

The actual attributes added to the schema, and their usage, should be pretty familiar as a subset of what was used in the OAM 10g days, and they are described in the product documentation here, so I won't repeat them. What has changed (from R1) is the way in which these attributes are manipulated by OAM at login time, in order to track user behaviour and also to occasionally force redirection to OAM password management URLs where appropriate. Any external user management processes would need to be aware of these attributes and be sure to interact with them in appropriate ways. As an example, consider the obPasswordCreationDate attribute, which keeps track of the time that the password was last updated in order to determine when to expire passwords, as well as when to warn users that passwords are nearing expiry. OAM 11gR2's own password change pages will ensure that this attribute is correctly set when a user does a self-service password reset, but if, for example, there is some external process within the organisation that allows an administrator to reset a user's password "out of band" from an OAM point of view, it is important for that process to set obPasswordCreationDate correctly when a password is changed.

The other important caveat here is to ensure that the LDAP directory itself is not going to enforce any native password policy rules that would conflict with the OAM policy. As an example, OAM's policy allows you to specify a maximum number of failed login attempts before the account should be locked. This is tracked via the obLoginTryCount attribute, which is manipulated by OAM at authentication time. Let's say for example that OAM defined a maximum of 5 failed login attempts before locking the account; having a lower threshold defined at the LDAP level (3, for instance) could, of course, cause inconsistent behaviour, with the directory itself denying a bind request that should be valid according to the policy defined in OAM.

I guess the really important thing is to properly analyse your password management requirements before you start and decide whether OAM's password policy is the route you want to go down, or whether it might be better to look at keeping it in the directory (or elsewhere). Trying to manage a split password policy deployment would probably be more trouble than it's worth.

Password management use cases

Let's finish off by looking at a number of common use cases, to see which of them can be done using OAM 11g R2 only, as opposed to those which still need the OAM-OIM integrated scenario in order to be realised.

OAM 11g R2 can handle the following without needing OIM:

• Force password change on first login after reset
• Warn before password expiration
• Force password change on expiry
• Track failed login attempts and lock account after too many
• Automatically unlock locked account after configurable period

Anything outside of that will (currently) require a different solution, with the OIM option, in particular, used to handle the following:

• User-initiated (i.e. unsolicited) password change
• Lost password recovery (via password Q&A)
• Q&A challenge setup
• Self-service registation
• Self-service profile management

I guess that's enough for now. Let me know in the comments section if we need any further clarification on this functionality. In a future post, we'll explore how a hybrid solution including both OAM password policy, and OIM, could work.