What is identity management? Answer to that question is both easy and very complex. The easy part is: Identity management is everything that deals with managing identities in the cyberspace. The complex part of the answers takes the rest of this document.

User Accounts

The central concept of identity management is usually a data record that contains a collection of data about a person. This concept has many names but the most common are: account, persona, user record, user identity. Accounts usually hold the information that describes the real-world person such as person's given name and family name. But probably the most important part is the technical information that relates to operation of an information system for which the account is created. This includes specification of home directory, wild variety of permission information such as group and role membership, system resource limits, etc. User accounts may be centralized and unified, distributed and unaligned or anywhere between these two extremes. But regardless of the architecture the aim of identity management is management of accounts.

Identity Management Technologies

Identity management is not single technology. In fact it is a wild mix of various technologies that both complement and overlap each other. There are at least three main technological branches in the identity management:

Although these technologies formally form a single field of identity management their purpose and approach is significantly different. Any complex identity management solution will need at least a bit of each of them. These technologies are be explained below in much more details.

Identity Store

Accounts are stored in the databases called identity stores. The underlying technology of the database varies, ranging from flat text files through relational database to directory servers. Especially directory servers accessed by LDAP protocol are very popular because of their scalability. Identity store may be integrated with the application that is using it or it may be a shared stand-alone system.

Shared identity store is making user management easier. The account needs to be created and managed on one place only. Authentication happens in each application separately. But as the applications use the same credentials from the shared store the user may use the same password for all the connected applications.

Identity management solution based on shared identity stores are simple and quite cost-efficient. But capabilities of such solutions are considerably limited.

Identity stores are just that: storage of information. The protocols and APIs used to access such databases are primarily designed to be database interfaces. It means that they are excellent for storing, searching and retrieving data. While the data in account may contain entitlement information (permissions, groups, role, etc.) identity stores are not well suited to evaluate them. I.e. identity store can provide information what permissions account has but it cannot make a decision whether to allow or deny specific operation. Identity stores also do not contain data about user sessions. It means that identity stores do not know whether user is currently logged in or not. Some identity stores are frequently used for basic authentication and even authorization, especially LDAP-based directory systems. But the stores were not designed to do it and therefore provide only the very basic capabilities. Identity stores are databases not authentication or authorization servers.

Meta-Directory and Virtual Directory


Single Identity Store Myth

Shared identity store is making user management easier but this not not a complete solution and there are serious limitations to this approach. The heterogeneity of information systems in the common medium-to-large enterprise environment makes it nearly impossible to implement single directory system directly for the following reasons:

Even using meta-directory or virtual directory mechanisms may not provide expected results, as such systems only provide the data and protocol transformation, but do not change the basic principle of directory services. A more complex approach is needed to manage the user's records in heterogeneous systems, especially in large enterprise environment.

Single directory approach is feasible only in very simple environments of almost entirely homogeneous environments. In all other cases there is a need to use also other identity management technologies.

Identity Store Implementations

Open source identity store implementations include:


Provisioning systems integrate many different identity stores. The goal of provisioning systems is to keep the identity stores as synchronized as possible (and practical). Priority of provisioning systems is to be non-intrusive. Provisioning systems do not try to change existing account data models in the applications. A provisioning system tries to adapt its own mechanisms to match the data model of each connected system. Provisioning systems are therefore quite complex and needs to be customizable and programmable. Adaptation of the data models is frequently done by using complex rules and expressions.

Provisioning system is just managing existing data stores. It is not doing any authentication or authorization on behalf of the application, that is job of access management. Therefore provisioning system is affecting the enforcement of security policies indirectly by manipulating data in other systems.

Provisioning Connectors and Agents

Provisioning systems can communicate with each application using application's own protocol or interface. There are two basic approaches:

Policies and Processes

Provisioning systems do not deal only with the technical aspects of the integration. Policies and processes are almost always part of provisioning system deployment projects. Most provisioning systems include its own version of workflow subsystem customized for identity management applications. It is usually quite easy to set up rules that automatically determine the basic accounts for a new hire and let system administrators approve the creation of such accounts. This is a unique aspect of provisioning systems when compared to other identity management technologies. Other technologies usually focus only on the technical side of the problem, not the business side.

Why Do We Need Provisioning?

Why do we even need provisioning systems? Isn't is easier to just deploy one single unified identity store such as LDAP server? Yes, it is easier. But it is possible only in a very simple situations (see Single Identity Store Myth above). Even if technical architecture favors the single identity store approach there are still non-technical issues. E.g. the single identity store will not appear in a day. Its deployment and integration may take a long time. Provisioning system is needed in the meantime. Also the applications cannot adapt quickly. E.g. many applications support LDAP authentication out of the box. But LDAP authentication is sufficient only for very simple applications. Complex applications usually needs local data records: accounts. Even is such accounts do not contain credentials (passwords) they still contain authorization data (roles, privileges, organization unit membership) that are not stored in the central identity store. Other application needs local data records to be able to do database join e.g. for the purpose of reporting. And even if the application can theoretically work with single identity store it may take years to make it work practically. In such cases provisioning system can provide solution much faster and often also less costly.

The support of processes in the provisioning system is yet another reason in favor of such solution. Identity stores present static data. But provisioning systems often deals with data changes. Therefore a provisioning system may enforce an approval of the change before it is applied. Provisioning system may send a notification after the data are changed. Provisioning system can also integrate manual processes into the identity management solution (e.g. legacy systems where identity management cannot be automated).

Deployment of a Provisioning System

TODO: heavy customization

Provisioning System Implementations

Open source provisioning system implementations include:

Access Management

Access Management and Provisioning

TODO: SAML deprovisioning problem

Mix It Up

TODO: combining a the complete solution

See Also