4

Time to get on the Bus? Traditional IDM Model vs Enterprise Service Bus Model

Share this content:
LinkedIn
Facebook
RSS

All aboard! Is it time to get on the Bus?

Traditional designs for Identity Management (IdM) Systems in the corporate world provide for a wheel and spoke architecture, but demands for greater performance, support for larger numbers of identities and a broader range of applications along with integration to cloud service providers are heralding a change of thinking with how we architect Identity Management Solutions for the future. I would like to challenge the traditional thinking for IdM to see if the use of Service Bus technology can provide some or all of these capabilities.

The traditional IDM model.

At the core of an Identity Management architecture is a central sync engine that pushes or pulls the data exchange between end points (that is, source and target systems). Data is sourced from one or more authoritative sources and placed or provisioned into multiple target systems including the authentication directory, typically AD. The central “engine” would house the sync engine and in many cases the Identity Vault. The Vault would in turn become the central store of all identity information but NOT necessarily the authoritative source for any specific attributes. The vault is in effect the single point of truth for all “relevant and required” identity data for downstream applications and targets. It may not hold all of a person’s identity information, but it provides the data to all downstream target applications, directories or databases that are required to manage that identities authentication, access and authorization levels. Its primary role is to store all Identity information aggregated from the sources. Many of these attributes, that comprise the Identity information in the Vault, are used to determine how specific rules and actions performed by the sync engine are used to determine specific provisioning requirements for each target system. This may include group membership, account placement, in the case of Active Directory structure, and other entitlements using attributes such as position and even employee type (e.g.: full time versus contract).
hub-and-spoke-idm-design

The data placed in the vault is an aggregation of data from multiple sources. While in many cases these are a one to one relationship, there are some cases where the rule are configured to aggregate data to make new attributes such as combining the first and last name of an identity to create a username with the first initial and last name.

e.g.: firstname + lastname = firstinitiallastname

joe + bloggs = jbloggs

Each Identity has a specific Unique Identifier that allows the IdM system to match the data for an identity in each target and source system. By providing a central engine to manage all identity data across each source and target, monitoring, logging and tracking is relatively easy and provides excellent material for forensic evaluation of entitlement allocation in the event of an audit required to determine what identities have access to specific applications and how those identities obtain those attributes. (i.e. Attestation).

 

The Enterprise Service Bus Model (ESB)

Introducing a bus topology to an Identity Solution can provide improved performance, a greater level of autonomy for target and source systems, and greater flexibility with the opportunity to use multiple tenanted systems. However, it does not provide the Identity Vault capability unless a specific vault is set up as a separate target to store aggregated Identity data. Even so, the bus based solution won’t provide auditing capability relying instead on the individual target and source systems to maintain their own rules for Identity provisioning and management.

The Enterprise Service Bus is simply a transport system. Each end point, whether source or target connects to the bus to read data or place data on the bus. The data has a Time To Live assigned to it ensuring that it remains for a short period of time only. Specific unique identifiers for each identity are still required to ensure data is assigned to the appropriate identity in each target system.

A source system exports the identity data by placing the data on the Service Bus. The bus provides a transport mechanism for data contributed by source systems which is consumed by “downstream” or target systems. Each system connected to the bus determines what specific attributes of the data it will consume and whether any specific changes are required for the target system of the data. The architecture provides a greater level of decision making with respect to the consumption and transformation of the data by individual target systems rather than a central rules and sync engine, which in turn provides an enhanced performance of the IdM solution. The aggregation of data to form new attributes is performed by the target system as per its specific requirements. This may include data for an identities email address sourced from the email system, or phone number sourced from the phone exchange, or any number of authoritative sources for specific identity information. No single identity vault exists with the logging of changes to specific identities in each target and source system handled by the individual end point system.

enterprise-service-bus-idm-architecture

Summary

The prevalence of cloud-based applications, the growing number of identities within corporate environments (staff, partners and consumers) and the need to ensure ongoing security of identity and corporate data, demands that we revisit the Identity Management model to see whether the traditional model can manage these requirements into the future. Identity Management systems are complex and expensive. Large corporate environments need reporting, monitoring and auditing capability within their Identity platform to ensure security of data and identity information as well as forensic capability to manage any breaches that may occur. Smaller organisations do not have the auditing and reporting overhead but require a cheaper solution that can handle large identity numbers through consumer identities and possible as many SaaS or on-premise applications to access.

While the Bus topology may not support all of the needs for a large corporate environment, it may be feasible to suggest that a enterprise bus based Identity Management solution would fit the requirements of smaller, medium sized organisations. Identity Management is the new security firewall for organisations extending their boundary from the traditional firewall based model to adopt Cloud based services. All organisations need to engage a secure Identity system to provide the flexibility and service for their future needs.

Perhaps these organisations need to get aboard. The call is out. Is it time to get on the bus?

Martin Klein

4 Comments

  1. Thank you for excellent article. Your explanation of the traditional idm system is perhaps the best one I have ever seen. May I ask what is the origin of the ESB model ? And is there any product that has tried to incorporate the model into current products ? Or do we need totally another line of products for the ESB ?

    • Hello Janne, Thanks for your kind comments. To answer your questions, the ESB model was derived from experience with some customers and ESB vendors looking to use their products to fulfill Identity Management requirements. To date these have been architected as a hybrid solution utilising components of a traditional model with an ESB. I am not aware of an ESB vendor who has included the capabilities around audit or reporting or an identity vault needed for IdM services Hopefully we will see a new line of products built from the existing products that will deliver the functionality and performance required.

  2. I definitely support this concept for systems where integration with IAM would be incredibly valuable, but a loosely-coupled relationship is what’s needed. In particular where requested access is handled through a Service Catalog or Service Desk system, but we want IAM to implement, enforce, attest and expire the access. Having the two systems directly dependant on each other could cause all sorts of problems, while passing messages “please do this”, “now done” on the ESB allows each service to work on it’s own schedule or workflow processes without the direct dependency.

  3. I was part of implementing ESB for a large company and exactly we ran into the same issue with “reporting”. However, the performance is incredible and none of the vendors in the market can come close to it. The downside is, it took two years of development with 10 plus developers and burning midnight oil. If you don’t have strong developers/operational support then I do not encourage this approach

Leave a Reply

Your email address will not be published. Required fields are marked *