Provisioning is the process of preparing an IT system to provide service to a client, customer, or other user. From the perspective of digital identity, provisioning is the creation of the identity record and its population with the correct attributes. These attributes might be standard items, such as name, location, email, and phone, as well as items more specific to the system. For example, the identity system that feeds the custom page presentation system for My Yahoo! contains attributes such as page color, positioning, and so on.

Provisioning can be done through the action of an administrator, or it can be self-service, occurring as a result of user actions. When a new employee joins a company, administrators, usually on multiple systems, provision identities for that employee so that she can be assigned an office, get on the payroll, get a computer, get a badge, become part of the health plan, and so on. One of the trends in enterprise computing has been termed “zero-day start,” meaning that the enterprise links all of these systems so that when a new employee starts, all of the systems, permissions, and infrastructure are set up and ready, allowing the employee to start work the first day and have access to all of the resources, physical and virtual, that she needs to be productive.

We’re all familiar with self-service provisioning—we see it every day on the Web as we visit web sites and sign up for services, both paid and free. For example, I’ve had a virtual server account with Verio for six years, and I’ve never talked to a human. I signed up online, and I manage the account entirely online. Self-service provisioning is a hallmark of the Internet age and perfect for services that are delivered over the network. Self-service provisioning works well where there is little need to verify credentials other than perhaps a credit card.

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.

The use phase is probably the most obvious of all the phases in the lifecycle. Once the identity has been provisioned and propagated, the identity is used by various systems and agents. This might be as simple as consulting the identity to authenticate and authorize user actions against resources, or it could include more complicated actions, such as billing or payroll.

Regardless of the nature of the identity, the attributes will change from time to time, either because the base attributes of the entity change (e.g., a new home address) or because roles and assignments change. Often, to support new business opportunities, the schema of the identity record may need to be changed to add new fields to or include entirely new systems.

We’ve seen that identities are often about things other than people. In these cases, it’s possible that the entire entity referred to by the identity is changed. As an example, consider upgrading the departmental laser printer. The name and IP number for the printer may be the only attributes that remain the same. This same phenomenon occurs when people occupy positions with strong role-based identity (e.g., the on-call duty officer).

All of these actions result in changes to the identity that, after completion, must be repropagated to the affected systems.

Maintenance of identities is one of the most costly activities that an IT help desk deals with day to day. Users frequently lose or forget passwords to systems. They change roles or move. The more things users can do on their own, the more money the company can save in maintenance calls to the help desk. Password reset has become of one of the driving forces behind enterprise identity management systems for this very reason. Often, an identity management project can be justified on the basis of savings from building a self-service password system alone.

Just as important as the notion of provisioning is the idea of deprovisioning : removing identities from the system once they are at the end of their lifecycle. One employee of a company whose identity systems have won some acclaim told me that the company’s sophisticated identity management system had ensured he was ready to start work the same day he started. Ironically, two years after he quit, his voicemail still functioned. This company was doing a good job of provisioning, but had fallen down on the deprovisioning task. Leaving a voicemail account active may not be such a big deal, but leaving an employee with access to a sensitive system could be catastrophic.

Failure to properly deprovision an identity can lead to confusion, access to critical data by outsiders, and even fraud or theft. Old accounts, left active long after an employee is gone, are to blame for one of the largest security holes faced by many companies. These are dangerous for two reasons. First, the employee may continue to use company resources after she’s quit. More often, however, these accounts represent prime places for hackers to crack into corporate systems, because they are unmonitored and strange activity won’t raise any eyebrows.

Planning for each phase of the identity management lifecycle is critical to designing your identity management architecture and building a digital identity infrastructure. This planning can’t simply be done at the abstract level, but must extend to each subsystem that the enterprise operates. For example, the customer relationship management (CRM) system and the enterprise resource planning (ERP) systems have different sets of identities and have their own unique needs in each stage of the lifecycle. Later, we’ll discuss identity management architectures in some detail and see how an identity management architecture helps define the business context so that these different identity requirements can work together.