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 3 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.

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.


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. Identity stores are databases not authentication or authorization servers.

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.



Access Management

  • Authentication
  • Authorization

Access Management and Provisioning

TODO: SAML deprovisioning problem

See Also

  • Persona Model
  • No labels