Wednesday, September 20, 2006

Password Management with Third-Party Solutions

From my earlier posts you will know that passwords no longer need to be maintained in the E-Business Suite when you've implemented Single Sign-On 10g integration. What happens to passwords in a configuration that includes a third-party LDAP directory like Microsoft Active Directory, and a third-party single sign-on solution like Microsoft Kerberos?

Third-Party Integration In A Nutshell

Before we get to password management, I'd recommend that you review the earlier post.

If you're in a hurry, here's a quick recap of the key points:
  • Oracle Internet Directory is a mandatory hub for synchronizing user information between a third-party LDAP directory and the E-Business Suite
  • The third-party LDAP directory is usually considered to be the master "source of truth" for user credentials

  • Oracle Single Sign-On is a mandatory prerequisite for delegating E-Business Suite's user authentication to a third-party single sign-on solution
Using Oracle Internet Directory As A Hub

Recall that it's possible to integrate your E-Business Suite environment with a third-party LDAP directory using Oracle Internet Directory and its Directory Integration Platform as an intermediary, like this:

Third-Party LDAP Integration 2:

Oracle Internet Directory is a mandatory component in this chain. Oracle doesn't currently offer any methods of directly integrating a third-party LDAP with the E-Business Suite.

Third-Party LDAP As The Master "Source of Truth"

In the typical configuration, the third-party LDAP directory is the master "source of truth" for the user's credentials. For example, a change to the user's name would first be made in the third-party LDAP. The updated user's information would then be sent to Oracle Internet Directory via the Directory Integration Platform. Once in Oracle Internet Directory, the updated user's information would then be sent to the E-Business Suite via the Directory Integration Platform.

Extending the Chain of Trust

Remember that the E-Business Suite can delegate user authentication to Oracle Single Sign-On, effectively creating a chain of trust between the two components. When the E-Business Suite is integrated with a third-party single sign-on solution, that chain of trust is extended one level further, like this:

Third-Party SSO Integration:
When the user logs on to the third-party single sign-on solution, she gets a set of security tokens that are recognized and trusted by Oracle Single Sign-On. Oracle Single Sign-On doesn't challenge the user again for her credentials.

In turn, Oracle Single Sign-On issues its own set of security tokens, which are recognized and trusted by the E-Business Suite. The E-Business Suite doesn't challenge the user again for her credentials.

What About Passwords?

Now that we've got the basics out of the way, understanding how passwords are handled in this scenario should be a bit easier. In the scenario above, the user is challenged only once for their userid and password. The third-party single sign-on solution handles that challenge and authenticates the user's credentials against the third-party LDAP.

It stands to reason that if the user is already logged in by the third-party single sign-on solution, and Oracle components never ask for the user's userid and password, there's no reason to keep the user's password anywhere in the Oracle namespaces.

Passwords Stored In Third-Party LDAP:

And, that's true: when integrated as shown above, users' passwords are not stored locally in either Oracle Internet Directory or the E-Business Suite. Passwords are stored only in the third-party LDAP directory.

Delegating User Management

Since the third-party LDAP repository is the master source of truth, it handles all user password resets. Neither Oracle Internet Directory nor the E-Business Suite are interested in -- or even participate in the process -- of password management in this scenario. It's all delegated to the third-party LDAP.

For Advanced Readers Only

By this point, I've weeded out readers with short attention spans. For the handful of you who've toughed it out to this point, I should note that the above scenario is only one of many possible starting points. Other advanced scenarios are technically feasible, including those in which user credentials flow bidirectionally between Oracle Internet Directory and the third-party LDAP.

These can get pretty involved, so I'll have to leave these as an exercise for you to work out, for now. More information can be found in the Implementation Guide, which describes more variants on the basic scenario outlined here.

Related

Note: Everything in this article applies equally to both Release 11i and 12 environments.

No comments: