Propagating

Depending on the nature of the system on which the identity is created, the identity record may need to be propagated to other systems as part of its lifecycle. For simple systems, the propagation is as simple as writing the identity information to the filesystem or storing it in a local database. More complex systems may provide some sort of shared identity directory where the identity created in one place is used by multiple systems. In Chapter 9, we'll discuss metadirectories and virtual directories, which allow multiple directory systems to be linked together.

When I was CTO of iMall, we built a large e-commerce system that allowed small merchants to sign up for an account and then create a full-service online store. The system had a self-service account management system that allowed merchants to provision an account. Once the account was created, the identity information was propagated so that the system could create directories and files on numerous systems, add records to databases on other systems, and even establish a merchant banking account through an outside partner. This propagation of identity information was critical to the overall functioning of the system.

Propagation must occur after each change to the identity records, and the propagation must happen reliably. Because not all of the systems interfacing with the identity infrastructure support the notion of transactions (atomicity across multiple independent actions), this can be a challenge. To see why, consider the example I gave in the last paragraph. Suppose you create an account and the system creates files and database records, only to discover that the customer's payment has been declined. The system is in a state of partial completion, and backing out to a clean state is often nontrivial. The more actions involved in a single propagation, the more difficult this problem becomes. For such systems, the only alternative is to carefully think through compensating actions and when they should be applied.