Identity Management Solution Patterns

When it comes to identity management solutions it is everyone's dream to manage identities and access it centrally for all the applications and services in their ecosystem. This dream could be made a reality only if you are starting on a green field where there aren’t any applications or services that deal with identities or identity management.

Most often than not, you are faced with the challenge of implementing identity management for heterogeneous applications or services that don’t do identity management in the same way. Therefore a simple solution that consists of a centralized identity management system, to which all the other applications and services in your ecosystem would connect to and rely on for identity management, may not work. However, there are some well-established solution patterns around identity management that may help you solve this problem.

Though we generally tend to talk about identity management and access control as two separate concerns, they work hand-in-hand and complement each other. There isn’t any useful existence of one without the other. In this post, our focus is going to be on identity management and not access control. However, in order to discuss identity management of an application or service, we also need to consider how access control will happen for that application or service.

Different applications and services in your ecosystem might have different capabilities of identity management and access control. Not all applications and services will support the same set of capabilities. Therefore in order to choose the optimal solution for your entire ecosystem, it might be a good idea to evaluate each application and service in your ecosystem individually and choose the optimal solution.

Identity Management

Identity management is primarily concerned with the management of the following elements:

1. Identities and Groups — digital identifier, claims and groups of identities
2. Relationships — parent-child, siblings, owner, superior-subordinate, associations, etc.
3. Credentials
4. Entitlements

Externalizing identity management to a different application or service, will make it simpler, streamlined and consistent. However, not all applications and service will provide the capability to externalize the management of the elements we saw above. The most common element to be externalized is credentials. That is, most applications and services provide the capability to delegate credential management or authentication as a whole to external applications or services. This is possible due to standard protocols such as LDAP, SAML2 Web SSO, OpenID Connect, etc.

When externalizing credential management or authentication, if you are dealing with multiple sets of credentials for multiple applications then you need to devise a strategy to choose one set of credentials to be tied to the identity going forward and discard the rest.

The second most common element to be externalized would be the identities and groups. Again protocols like LDAP, SAML2 Web SSO and OpenID Connect help in doing this. Externalizing the identities and groups provide a consistent profile of the identity across all the applications and services.

The third most common element to be externalized is entitlements. Role Based Access Control (RBAC), Attribute Based Access Control (ABAC), Policy Based Access Control (PBAC), and authorization frameworks such as XACML, allow entitlements to be standardized and delegated. Externalizing entitlements provide centralized governance, auditing, and reporting of user access. However, it is not yet very common to see popular cloud service providers who can completely externalize entitlements.

The least common element to be externalized is relationships, mainly because there aren't any widely accepted standards to represent relationships across applications and services.

Following are the identity management solution patterns we commonly find to manage the above elements. You may have to choose one or a mix of many to manage all the elements we've looked at.

1. Sharing
2. Synchronization
3. Delegated Identity Management
4. Federated Identity Management

Sharing

This is about sharing the elements of identity we saw before between applications and services.

Though the following terms are not fully standardized they are in common parlance. The store in which identities and groups are managed is known as identity store; the store in which attributes are managed is known as attribute store; the store in which credentials are managed is known as credential store; the store in which entitlements are managed is known as the entitlement store. In practice however, it is common to find implementations of two or more of the above stores combined together.

Depending on the capabilities of the applications and services, identity stores, attribute stores, credential stores and entitlement stores could be shared. This is one of the easiest solutions for identity management.

Figure 1: Sharing identities, credentials, attributes and entitlement stores among service providers

Another important point to consider when following this approach is, if you are writing to the shared store from multiple applications, depending on the caching strategy the changes might take a while to replicate to the other applications.

However, sharing may not be possible in all situations, such as

1. If the application doesn’t support the same type or schema of data store
2. If the application/service is in the cloud and the data store is inside your network
3. If the application/service is outside your network, but the data store is inside your network
4. If external users are are accessing your internal applications and their data store is in their network

Synchronization

This is about synchronizing the elements of identity we saw before between applications and services. Synchronization can happen at two levels:

1. Synchronization at the data store level
2. Synchronization at the application level

Synchronization at the data store level can be following either multi-primary replication or a primary-secondary replication technique. However, this approach has the disadvantage of vendor lock-in and incompatibility of the data store technology of the various applications and services.

Synchronization at the application level can be further classified into

1. Vendor specific technologies such as Microsoft Azure Active Directory Connect, Google Apps Directory Sync and Salesforce Identity Connect.
2. Standards based provisioning services and clients such as SCIM or SPML which also support bulk operations
3. Non-standard approaches that may or may not support bulk operations

As with data store level synchronization, using vendor specific tools will result in vendor lock-in and incompatibility.

Following standards based provisioning services and clients such as SCIM and SPML is a relatively better approach that avoids this.

Figure 2: Identity Provisioning Bridge — Synchronizing identities, credentials and attributes among service providers

Sometimes we may run out of options to use vendor specific tools or standards based provisioning for certain applications or services. In those cases we might have to look at non-standard provisioning approaches as well. Non-standard approaches may need more effort to setup.

1. Implementing custom provisioning services and clients
2. Implementing custom connectors for identity stores, credential stores, attribute stores or entitlement stores
3. Implementing a custom user sync process

Figure 3: Setting up a user sync process

Delegated Identity Management

In most organizations today identity management is delegated to an identity broker, which is responsible for managing identities on behalf of applications and other service providers. This eliminates the problem of creating identity silos and the overhead of managing them in each of the applications or services.

Figure 4: Delegated authentication with an identity broker

Just-in-time provisioning is a key part of delegated identity management, which is used to provision accounts, credentials or entitlements for identities on the fly in the application or service, if the application or service cannot completely externalize managing one of these elements.

Federated Identity Management

Federated identity management is an arrangement that can be made between two or more trust domains, to let users of those domains access applications and services across the domains using the same digital identity.

Inbound identity federation allows external users access to your internal applications using their existing identities in their respective domains.

Outbound identity federation allows your internal users to access external applications and services using their existing identities in your domain.

Access Control

Access Control in relation to identity management is primarily concerned with the the following aspects:

1. Identification: the process of establishing the link between a digital identifier provided by a user and the digital identity of that user. It does not mean that the user has been verified to be who (s)he claims to be using the digital identifier
2. Authentication: the process of verifying the link established by identification, using some form of secret credential
3. Authorization: the process of verifying that the user is entitled to perform the operation s(he) requested

With sharing and synchronization approaches, access control will still remain within the scope of the application or service, because identity management still remains within the scope of the application or service. However with identity brokering and identity federation there could be changes from how identification, authentication and authorization was done previously from inside the application, and following is how they possibly can change.

Identification could still remain within the application if an identifier is still provisioned in the application for each user. Or else identification will be completely delegated to the identity broker.

Authentication can happen in one of the following approaches:

1. Initiating an authentication flow from the application or service to the identity broker (agent based)
2. Verifying an assertion that is coming in the request (proxy based)

Authentication requests can be initiated using either backchannel web service calls or front channel redirect based protocols such as SAML2 Web SSO or OpenID Connect, depending on the capabilities of the application or service and the identity broker.

Authorization can happen in one or more of the following approaches:

1. As part of the delegated authentication flow in the identity broker
2. In the application or service using the identity and its attributes returned in the authentication assertion as part of the authentication response
3. In the application or service using authorization assertions returned as part of the authentication response
4. In the application or service by calling back channel web services such as the Rest Profile for XACML 3.0

Summary

In this post we took a look at some popular identity management solution patterns that may help you plan your identity management strategy. In order to thoroughly evaluate your identity management strategy you also need to understand how access control will work for each of your applications and services.

The WSO2 Identity Server is an open source IAM product, distributed under the Apache 2.0 license, that possesses a powerful identity management and identity federation framework. It gives it the ability to support all kinds of identity management requirements in your IT landscape as described in this post.