Wednesday, December 12, 2012

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.


  1. Excellent post Rob. I was little confused with so many changes from OAM 10g to 11g r2. Oracle documentation doesn't go to this level of details. I'm looking forward to your post on the hybrid solution (OAM-OIM)


    1. Hi Nishant

      Thanks for the feedback. Will write more on this topic soon.


    2. Thanks for your knowledge share.
      I have learned so much form that.

      As you mentioned above,OAM consider
      the obPasswordCreationDate attribute to determine which page to
      redirect.but i don't know that OAM how and when to expire passwords.

      the obPasswordCreationDate attribute was changed each time the password was
      changed via OAM own password change pages. but
      the obpasswordexpirydate attribute in OID not be changed.
      even the password was reset.

      is that a default expiration period in OAM?

    3. Hi Rob,

      Thanks for the post.

      For our customer, we want to implement "Force password change on first login after reset" using OAM 11g r2. We cont have OIM integration. In you post you have mentioned that it is possible. But as part of password policy in OAM 11g R2 , I dont see an option to do that. Can you suggest how to do this? We have ODSEE as back end store. We have imported all OAM related schema to ODSEE. Does OAM understand that the password is reset and return appropriate Error Code . I dont see any error code in for password that is reset.


    4. @Gary - I'm not sure I understand your question here. According to the docs:

      The time after which the user password is considered to be expired.

      Now the password policy itself has a setting for "Expire after X days" with a default value of 20.

      So it follows that if the password was last set more than 20 (or whatever) days ago, it will be marked as expired.

      Please can you explain further what you are seeing that contradicts this behaviour?


    5. @Soby - nice to hear from you, hope all is well.

      Bear in mind here that the OAM password policy features in R2 are aimed at the end user, not the administrator. Hence OAM provides no pages or functionality allowing an administrator to reset a password; that would need to be done by either OIM, or by some other process/system outside of OAM.

      This explains why there is no "force password change after reset" checkbox on the OAM policy. It makes no sense to force a user to change their password again after they have just changed it!

      The answer here is to set the "obPasswordChangeFlag" attribute to "true" when doing an administrator reset. OAM will read this value and redirect the user as appropriate. Note that this is done as part of authentication, by the Password Policy AuthN Module. It is not handled as an error condition on authentication failure, hence your documentation reference is not applicable.

      Hope this helps you.


  2. I have a need to be able to set the password policy in oam via command line.
    Can this be done via wlst or can you point me at the config file these parameters are stored in?

    1. Hi Zafar

      I believe the password policy settings are stored in the OAM database and that WLST would be the correct way to set them via command line. However, at this time, there is no mention in the R2 Admin Guide of any WLST commands to modify these settings. I would suggest raising an S/R on this point.



Note: Only a member of this blog may post a comment.