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.
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 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.
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.
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.
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 technologies are focused on application back-end without affecting the front-end in any significant way.
Provisioning systems can communicate with each application using application's own protocol or interface. There are two basic approaches:
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 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).
The deployment of a provisioning system is usually quite a complex project. Not because the technology itself is complex but because the problem that the project solves is complex. If you need to deploy a provisioning system it s very likely that you have many identity stores to integrate, several sources of information that are only partially authoritative, messy business processes and so on. Even though provisioning deployments are complex it is the best solution to these problems that we know of.
Provisioning system are always customized during deployment. This may be a small customization or a huge one, but some customization is always there. The most important difference among provisioning products is the customization approach. Some products are little more than a platform that requires to develop almost everything during deployment (e.g. OpenIDMv2). Such products are extremely flexible but may be relatively costly to deploy especially if your environment is quite the usual one. Other products implement many common IDM scenarios out of the box while still allowing some space for customization (e.g. midPoint). These products are generally easier and less costly do deploy but may not be suitable if your environment is miles away from the usual thing. There is no "one size fits all" when it comes to provisioning. It is important to select the right tool for the job.
Open source provisioning system implementations include:
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. Access management technologies are focused on application front-end as opposed to provisioning which is focused at back-end. Access management changes how is the user authenticated and authorized to access the applications.
Following figure illustrates theoretical case of the access management deployment. The access management systems acts as a mediator to all access to all applications. Access management system authenticates and authorizes the user based on the identity information stored in the identity repository. In case that all access checks pass the user is allowed to access the application.
Access management should provide all necessary access control mechanisms to the application. It can also easily provide single (or simplified) sign-on as user session data are stored in the access management system and therefore can be shared across applications. That's the theoretical case. But the practice is slightly different.
Access management system should theoretically simplify the applications as they do not need to implement their own access management mechanisms and no other identity management mechanism should be required. However there are practical problems:
Aor not. But it cannot decide if the user is authorized to modify property
fooin a record number
1234in that application. Therefore applications must very often implement their own additional authorization mechanisms. For that reason the applications must maintain their own user records (accounts) or must have back-end access to the identity repository.
Access management is an umbrella term for quite a wide range of mechanisms. Some access management systems deals only with authentication or single sign-on (SSO), others also deal with authorization, some are focused mostly on web applications while other work only in enterprise environment where client machines can be strictly under control. Individual access management systems provide partial solutions to the identity management problems and they almost always must be combined with other identity management technologies.
TODO: Single Sign-On (SSO) is sometimes considered to be a part of access management.
TODO: web SSO vs "true" SSO (e.g. kerberos)
TODO: quite rough
TODO: single identity store: how to create it?
TODO: SAML deprovisioning problem
TODO: combining a the complete solution