Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 13 Next »


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:

  • Identity Stores store user account information. It is usually assumed that the identity store is exposed to other systems over the network and that it is shared among many applications but that is not always the case. LDAP directory servers, Active Directory and portions of relational databases are examples of identity stores.
  • Provisioning is a branch of identity management that focuses on management of many identity stores. Provisioning systems are complex mechanisms that synchronize account data across broad range of data formats, models, meanings and purposes. Provisioning systems usually contain sophisticated expression and rule engines, workflow mechanisms, policy evaluation and enforcement and so on.
  • Access Management deals with user authentication and (partially) authorization. The goal of access management is to unify the security mechanisms that take place when a user is accessing a specific system or functionality. Single Sign-On (SSO) is sometimes considered to be a part of access 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:

  • Lack of a single, coherent source of information. There are usually several sources of information for a single user. For example HR system is authoritative for the existence of a user in the enterprise and for assignment of employee identifier. The Management Information System is responsible for determination of user's roles (e.g. in project-oriented organizational structure). The inventory management system is responsible for assigning telephone number to the user. The groupware system is authoritative source of the user's e-mail address and other electronic contact data. There are usually 2 to 20 systems that provide authoritative information for a single user.
  • Need for a local user database. Some systems must store the copies of user records in local databases to operate efficiently. For example large billing systems cannot work efficiently with external data (e.g. because relational database join is not possible). Legacy systems usually cannot access the external data at all (e.g. do not support LDAP protocol).
  • Stateful services. Some services need to keep state for each user to operate. For example file servers usually create home directories for users. While the automation of state creation can usually be done on-demand (e.g. at first user log-on), the modification and deletion of state is much more difficult.
  • Inconsistent policies. The role names and access control attributes may not have the same meaning in all systems. Different systems usually have different authorization algorithms that are not mutually compatible. While this issue can be solved with per-application access control attributes, the maintenance of these attributes may not be trivial. A complex tool for transformation and maintenance of access control attributes (usually roles) may be needed.

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:

  • OpenDJ: LDAP directory server written in Java.
  • OpenLDAP: LDAP directory server written in C.


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.

TODO: figure: provisioning system

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.


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:

  • MidPoint: complex and efficient complete provisioning system.
  • OpenIDM: flexible and programmable provisioning platform.
  • Syncope: provisioning system build on top of relational database.

Access Management

  • Authentication
  • Authorization

Access Management and Provisioning

TODO: SAML deprovisioning problem

Mix It Up

TODO: combining a the complete solution

See Also

  • Persona Model
  • No labels