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 20 Next »

Introduction

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

TODO

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

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 Connectors and Agents

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

  • Connectors are pieces of code running on the side of provisioning system. In this aspect they are similar to the database drivers. Connectors expose application's objects (accounts, groups, ACLs, ...) to the provisioning system. Connectors use various kinds of remote protocols or APIs for that purpose. Connectors are non-intrusive and do not requite any installation on the application side.
  • Agents run on the application side. Similarly to connectors agents are exposing application's objects to the provisioning system. Agents are intrusive and require installation (and integration) on the application side. However agents can use also local APIs and may be much more powerful than connectors.

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

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.

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

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.

Practical Access Management

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:

  • Almost all applications already implement authentication and authorization mechanisms so almost no simplification is applicable in a common case. It may even be quite difficult to replace existing mechanism with access management which may significantly complicate the system.
  • Access management system assumes an existence of a single unified identity repository. But that is seldom the case unless the repository is a result of other identity management mechanisms (e.g. provisioning).
  • Access management system knows very little about internal structure of the applications. Therefore the ability to decide and enforce authorization is severely limited. E.g. the access management system can decide if a user can access application A or not. But it cannot decide if the user is authorized to modify property foo in a record number 1234 in 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 can provide authorization services only if a user is accessing the system. While that is usually the case there is still significant number of cases when an operation has to be executed on behalf of the user while user is not online. E.g. scheduled tasks, asynchronous invocation, automated reaction to external messages, etc. Access management technology cannot handle these cases by its own.

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.

Authentication

Single Sign-On (SSO)

TODO: Single Sign-On (SSO) is sometimes considered to be a part of access management.
TODO: web SSO vs "true" SSO (e.g. kerberos)

Enterprise Single Sign-On (ESSO)

TODO

Authorization

TODO: quite rough

Access Management and Provisioning

TODO: single identity store: how to create it?
TODO: SAML deprovisioning problem

Mix It Up

TODO: combining a the complete solution

See Also

  • Persona Model
  • No labels