Enterprise Identity and Access Management

Meta-directory is a special directory system that synchronizes several "normal" directory systems. Meta-directory copies data. Therefore the performance of the original synchronized directory systems is mostly unaffected.

Virtual directory is a proxy and a protocol converter. Virtual directory creates unified view from several "normal" directory servers. Unlike meta-directory the data are not copied. Virtual directory fetches the data from the original directory on each request and converts them to the the unified view.

Some meta-directories and virtual directories can reach beyond common concept of directory, e.g. they can fetch data from relational database tables. Both meta-directory and virtual directories can convert data. However the data conversion ability of both meta-directory and virtual directory is very limited. E.g. it can convert number or date formats but usually cannot execute complex routines. They also cannot synchronize records that use a significantly differing data models. Entry correlation abilities are limited even more. Therefore meta-directories and virtual directories are suitable only for a very simple deployments. That might be one of the reasons that these directories are not used much any more.

IDM systems can usually do all that a meta-directory can do and are much more flexible. IDM systems can also act as virtual directories under some circumstances. However the performance of IDM system is usually worse than that of a meta-directory or a virtual directory.

Shared identity store is making user management easier but this is 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 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 users' records in heterogeneous systems, especially in large enterprise environment.

Single directory approach is feasible only in very simple environments or 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:

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

IDM systems do not deal only with the technical aspects of the integration. Policies and processes are almost always part of IDM system deployment projects. Most IDM 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. Users may also request additional privileges or permissions which may go through an approval process before it is granted. Some IDM system also allow re-certification of access privileges.

This is a unique aspect of IDM systems when compared to other IAM technologies. Other technologies usually focus only on the technical side of the problem, not the business side. IDM systems are the glue that connects business and technical sides of identity management.

Why do we even need IDM 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. 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. IDM 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 if 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 applications need 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, IDM system can provide solution much faster and often also less costly.

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

RBAC stands for Role-Based Access Control. It is a way how to sort permissions and privileges into roles and assign roles to users. The model was formally defined in 1990s and many information systems support RBAC internally. But that RBAC model is confined inside a single application and it is not easy to make it work across several applications. IDM system is a tool to do that. IDM system can create roles that spread several applications.

Although RBAC may seem like an easy an elegant solution there are some drawbacks. These issues are especially problematic in an enterprise-wide RBAC modeling which is a common task done during IDM solution deployment.

Usually the first obstacle that is encountered during an IDM deployment is incompatibility in RBAC models. RBAC model is simple, perhaps too simple for a complex deployment. Therefore applications frequently extend the basic RBAC idea with additional mechanisms, e.g. combining roles with work positions, locations and other parameters. RBAC extensions of one application is seldom directly compatible with other applications therefore a common data model is not feasible. Perhaps the most efficient way how to at least partially align the RBAC models is to the integration power of a IDM system.

When basic incompatibilities are handled there is another obstacle: role explosion. The number of roles required to define all the necessary permission combinations grows rapidly. If a static RBAC model is used to implement a least-privilege approach using a hierarchical RBAC model then it is quite common that the number of roles will be higher than the number of managed users.

Static RBAC model is not well suited for identity management applications. It needs to be extended with more logic inside the roles, e.g. conditions, expressions, etc. But even though there are drawbacks roles are usually necessary anyway. More generic models such as Attribute-Based Access Control (ABAC) are even more difficult to use in IDM. Such models rely on fact that permission is decided at the moment when a subject is accessing an object and that the entire context of the operation is known. However IDM system must decide long before that when account is created or modified. IDM system works more with instructions for decisions not with authorization decisions per se. Roles fit into that definition quite well because they are not evaluated in the IDM system. Roles are rather transformed to other authorization concepts that the systems understand: groups, permissions, ACLs, system-local groups or even system-local ABAC policy definitions. Such system-local concepts are in turn evaluated by the end systems at the time of user access.

The deployment of IDM 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 IDM 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 IDM deployments are complex, it is the best solution to these problems that we know of.

IDM systems 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 between IDM products is the approach to customization. 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 identity management. It is important to select the right tool for the job.

IDM systems are essentially complex data synchronization tools. Therefore there are several limitations that should be kept in mind when designing a deploying IDM solution:

And finally one obvious limitation which seems not to be obvious enough:

Open source IDM system implementations include:

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:

Access management is an umbrella term for quite a wide range of mechanisms. Some access management systems deal 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.

Typical access management system tries to do user authentication instead of the applications. The access management system authenticates the user and creates a user session. It then forwards or proxies the connection to the application. Application must be at least partially aware of that so it will not authenticate the user again.

Access management systems usually do at least some kind of authorization. However the ability of the access management system to provide authorization services is significantly limited. The access management system knows who is accessing the system (subject) but has only very rough idea about the operation and knows almost nothing about the object that the operation affects. Yet, knowing all three parts of the authorization triple is essential requirement for good authorization decisions. Therefore access management systems can do only a rough authorization decisions such as: "allow (any) access to system Foo", "allow HTTP POST operations to URLs that match the pattern /private/*", etc.

If a finer authorization is required that that must usually be done by the application itself. The application knows all the details about operation and object but does not have the details about subject. Therefore an application must be able to get the details of the authenticated user from the access management system.

Simply speaking, Identity Federation is just an SSO over the Internet. SSO usually assumes that both identity repository and the applications are in a single organization. Therefore the trust is implicit and the protocols may be proprietary. Federation goes a step further and makes no such assumption. Therefore there needs to be explicit trust and strong authentication of the communicating parties. Also the federation protocols must be open and the mechanism must be designed for the Internet use (e.g. must be robust and scalable). But otherwise the technical principles of SSO and federation are almost the same.

A simple federation scenario is illustrated in the following figure. Each color means a different organization connected over the Internet. One of the organizations is an Identity Provider. This organization maintains an identity repository that is used to authenticate users. After user logs in Identity Provider issues an assertion (federation token) to the user. This assertion is used as a proof of authentication. It may be presented to other organizations (Service Providers) that will let the user in. The assertion may be quite rich, e.g. containing also user attributes, privileges, roles, authorization decisions, etc. This may be used for further authorization by the Service Providers.

Probably the most popular federation protocol is SAML. There is also a mechanism called Cross-Domain SSO (CDSSO) which may seem as identical to federation as it is also spanning several Internet domains. But CDSSO is mostly used as a workaround to propagate usual SSO cookie across Internet domains and does not have other features of federation (openness, trust, robustness, scalability).

Access Management is a front-end identity integration technology. It means that it is changing the way how user interacts with the application. Even though the only aspect that changes is usually the way how user authenticates to the application there needs to be a change. The application or its supporting framework needs to have support access management solution. This least intrusive case is to configure the framework (e.g. Java EE application servers) or install a special-purpose agent. This way may be almost transparent for application when it comes to authentication and coarse-grain authorization. But if the access management needs to be integrated more tightly then the modification of the application is almost unavoidable.

The need to modify the applications to add access management support will come sooner or later. Access management system usually provide APIs and libraries to make such task easier but it is non-trivial task nevertheless. Such need will be come very soon especially if fine-grained authorization is needed. This may be further complicated if the security models of the applications and the access management system are not well aligned.

This requirement to modify the applications makes access management somehow intrusive technology. And also quite expensive to deploy.

Access management technologies usually require single, consistent and authoritative identity repository. This requirement is especially important if a Single Sign-On solution is being deployed. But how to get such a repository? Usernames are often not synchronized among applications. Therefore taking the identity repository of one of the applications does not usually work. That’s one of the reason why full-scale access management deployments usually fail.

Access management technologies seldom care about local state of the application. Therefore if an application needs a local user record the application must create it on demand when a user is first accessing the system. This is a common case especially in federated deployments. So the user gets provisioned automatically, on demand. But the user never gets deprovisioned. If the user account is deleted in the Identity Provider repository it just disappears. Service Providers are not notified. The user data remains on Service Provider side indefinitely. This is a potential risk of data exposure especially if additional (local) authentication or credentials reset was configured. But in any case it wastes resources and may cause unnecessary cost e.g. if per-user service pricing model is used.

IDM system is usually a prerequisite to an access management deployment. The IDM system has an ability and flexibility to create unified identity repository that can be used by the access management system. It is also well suited to keep several identity repositories synchronized. Therefore it can efficiently solve the deprovisioning problem. Large-scale deployment of an access management solution that lacks the identity management aspect can hardly be successful.

There is a large number of implementations that might fall into the access management category. To name just a few:

The key to the project is to know what needs to be integrated. When it comes to the identity management there are several types of systems:

Then there are systems that are sources of the data. The typical one is a Human Resources (HR) system which is usually an authoritative source of employee data. Then there is CRM which is a source of customer and partner data. And usually there are also contractors, independent agents, volunteers and many other types of users that do not have any authoritative source. And even if the source is authoritative for existence and status of an employee record it may not be entirely authoritative when it comes to the e-mail address or placement of the user in the organizational structure. The larger, more flexible and business-oriented is the organization the more complex is the resulting situation. Probably the only practical solution that can handle such situation is a IDM system.

Practical IAM solution requires combination of identity repository, identity management and access management mechanisms at the very least. These technologies complement each other as illustrated in the following figure.

IDM system is synchronizing accounts and user records through the organization. It pulls data from various data sources such as HR and CRM systems and creates an unified view of such data. It keeps the databases of legacy and stateful systems in sync. However its most important responsibility is to maintain shared identity repository. The identity repository is used by applications that are able to do so. It is also used by the access management system as a coherent and authoritative user database.

Identity management projects fail frequently. The typical identity management project is a big all-or-nothing waterfall-like project. That is not a project but a plan for a disaster and a huge waste of money. There are many reasons for that, but probably the most important is the lack of knowledge:

Waterfall-like project will not work. It may succeed to meet project goals but it will not bring expected value to the customer.

Divide the project into smaller steps and proceed in iterations and increments. Bring value in each step. Proceed only as far as it is efficient to proceed. Some tasks are still most efficient when done manually by a human. Set the basic structure and improve it in each step as needed. Avoid paying high licensing cost at the beginning of the project as this efficiently kills all value and ruins TCO. Either negotiate with the vendor or simply use open-source software.

The usual order of identity management technology implementation is:

The order is not simple IDM, repository, AM. It is iterative. Therefore it looks more like this:

Some steps may be reordered or even skipped. E.g. the first "Basic provisioning" step may be skipped if there is already a solid repository (e.g. Active Directory instance populated with employees). But that task will come back. The next iteration over identity management will be more difficult (e.g. if customers and partners also need to be in the repository). The effort might be slightly optimized but it will not change much on the overall project shape.