Advanced Password Services (APS) Guide › User Directories: Schema, Storage and Capabilities › Password Replication/Synchronization

Password Replication/Synchronization

APS, out of the box, does not support password replication or synchronization between multiple user directories.

This is not a simple subject, but deserves some attention in this document.

There are many technical problems with password replication. Here are a few of the bigger examples:

• Fault tolerance. What happens if one of the directories involved is not available when a password changes?
• Compatibility. What happens if a given password is allowed by the first directory, but not allowed by a subsequent directory (due to native password policies)? How does the process "roll back" the change already made on the first directory?
• Coverage. Unless implemented at the directory level, every application that changes user passwords must trigger the replication.
• Standards. Most directories do not implement a "Is This Password Valid" function so that applications can verify a password before saving it.
• Network Security. Passwords will have to be passed around, multiple times, on the network. Often in clear text, depending on directory support.
• Application Security. The password will only be as secure as the least secure data storage mechanism. Imagine an LDAP database, which usually stores passwords in hashed format: fairly secure. Now a new application using Microsoft Access is added and all password changes to the LDAP directory are replicated to the Access Database, which might store it in clear text. Now all of the applications at the site are compromised. Even if the Access application deems its security as sufficient for its own purposes, it may not be for the other applications at the site.

There are a number of reasons that sites consider password replication/synchronization. Some are better implemented in other ways, thus avoiding many of the problems listed above.

Shared Directories Some people are under under the impression that "Password Synchronization" must occur between "applications", even if the "applications" share a common user directory. This is actually a trivial case, since the credentials are only stored once and can (usually, but not always) be shared between the two applications (presumably, one of the applications is SiteMinder). With SiteMinder's broad User Directory support, this case of "synchronization" is non-existent (or trivial, depending on how you look at it). This, of course, depends on whether the applications require their own operational user attributes or can share the "native" ones.

• Hidden Directories—There are many cases where SiteMinder is protecting a web application that must, in turn, log into an underlying system, with its own (unsharable) User Directory. However, the user's interaction with that underlying system is exclusively through SiteMinder. Many jump to the conclusion that this requires synchronization; that the credentials passed to SiteMinder need to be used to log into the underlying application and therefore the credentials always need to be kept in sync.

  If the underlying system cannot be accessed through any other mechanism than SiteMinder, this synch is not needed, in fact. An alternate solution for this case is presented in the chapter on Best Practices for Storing Legacy/Back-End Credentials.

• Single Sign On to the Desktop —The Site wants users to have a single set of credentials for both the desktop and SiteMinder.

  Since SiteMinder supports both Windows Domain Directories and Active Directory, this is better accomplished using a shared directory than by replication. iPlanet (and possibly others) also has a replicator available to perform password synchronization at the directory level.

• Authentication vs. Data Directories—Some sites look at synchronization as a necessity when they have multiple data stores, all protected by SiteMinder, the data stores cannot be merged (for whatever reason), but they want to pull different data out of different directories for different applications. The example is a customer that defines two different User Directories, but the users are the same in each. Directory A is used for Application A policies and Directory B is used for Application B policies. They do this so that they can make authorization decisions or provide responses to resources from the correct directory.

  This case is trivially solved using SiteMinder's Auth/AZ mapping. In fact, without such mapping, no single sign-on is possible, since when the user will authenticates against different directories, SiteMinder will consider them different users.

• Multiple Directories—There are real cases where two (or more) user stores are used as User Directories by different applications and all of the applications are accessible through their own interfaces (not through common access control, such as SiteMinder).

  This case only occurs when two (or more) data stores are accessed independently, directly by the user and both are used for authentication.

  In these cases, sites cannot get Single Sign-On (because of the different access controls), but they want each user to have a single set of credentials that they can use to log into each application. When the credentials change in one application, they should change in all others. Things like forced password change, password expiration, etc, should be enforced according to common (or at least negotiated) rules.

  This is the only true Password Synchronization case and is actually quite rare. All of the other cases are better handled using other mechanisms.

  Note: The two directories involved are often otherwise unrelated and no other provisioning is required.

  Such replication is, however, still possible, even though it is not supported out of the box by APS. APS calls a specific function every time a user's password changes, passing the user identity and the new password. This function can be hooked to capture the change, and then the function can write the changes to any or all of the other places that it is needed.

  This function is part of the SmAPSEx library (described on Unsupported "Page" Cross-Reference), but is not publicly available in the SDK (imagine the possibility of Trojan horses capturing password changes). However, it is available to CA Professional Services to provide custom solutions.