Ad Image

Identity and Access Management Through the Enterprise Service Bus is a Pipe Dream

Identity and Access Management Through the Enterprise Service Bus is a Pipe Dream

Identity and Access Management Through the Enterprise Service Bus is a Pipe DreamDean Wiech, Managing Director of an IAM provider called Tools4ever has some some advice for those of you who think you can deploy your Enterprise Service Bus to effectively carry out identity and access management activities: it is a utopian ideal that you won’t achieve. While establishing the architecture of your system to handle identity with the ESB may seem to be an elegant solution, the intrinsic nature of how ESBs work will make all your hard work be in vain.

Dean wouldn’t have to write about this if the technique didn’t seem attractive at first glance. He describes ESBs’ IAM practitioner seduction technique:

The conclusion almost always is that ESB appears to be an ideal mechanism for managing the various types of digital profiles (identities) of a natural person on the network. For example, when an employee is entered into an HR system, a signal is sent to the ESB. In real time, the ESB then sends a message to the active directory and the user account is created.

Since this action is performed in real time, in contrast to batch handling in identity management, it is ideal for commercial organizations, where, for example, users need to have their accounts created immediately. Consider the example of a web store or a provider of training courses: The ESB works in accordance with a pure model, where the linked applications are “subscribed” on the ESB and these various messages are “published.”  So far, ESB seems ideal for managing identities in the network.

Wiech says don’t be lured by that siren call:

However, things work differently in practice, and there are a number of reasons why it is not ideal.

He describes several areas of incompatibility between your ESB and your IAM needs.

The first is the bi-directional nature of the ESB’s interface with the rest of your systems. This simply means the ESB can send and receive data and commands to any system it is connected to. Identity and Access Management processes don’t work the same way, however, as the type of data is “very different.” The changes involved, such as “a change in job or surname, or a promotion or departure of employees,” often can’t be read by the applications in their default modes, requiring significant development work on the part of the application supplier to make the system function. A result is that only very basic messages can be sent, such as the creation of a new identity. Even worse, many of the systems that would be crucial to setting up an ESB-based IAM system, such as HRM systems and electronic client dossiers don’t have ESB connectors available.

You’ll also have to hook up or build in an identity vault; a single central data store that has all relevant user identity information. This system would provide the ESB with the identity keys it would need to perform its IAM task, but that process adds another burden to the ESB’s long list of tasks.

A third problem is that the ESB is non-persistent. In other words, it doesn’t retain any of the data it handles, and deals only with “the retrieval and delivery of data” according to Wiech. This state of affairs makes it difficult for the ESB to serve as an effective IAM solution, as it will need to request other systems, potentially many of them, to process requests. You’ll need to hook up that identity vault again in order to give your ESB a shot at handling IAM processes.

Finally, ESBs were not designed to directly handle IAM reporting. In order to follow through on a command to make a report, the ESB would have to contact numerous systems multiple times each with multiple messages, placing a huge burden on that poor, mal-employed ESB. Weich once again suggests his idea of the identity vault as a one stop shop for easy reporting.

Weich then wraps by describing how data coverage for IAM-related data generally falls short of what the ESB needs to work well:

An ESB requires that all applications offer 100 percent coverage in supplying IAM-related data. We see that applications for stock management, for example, or in the ERP sector, are particularly good at providing access to this data via an ESB.

For IAM-related data, support for this generally falls short. The strategic choice for an ESB then has the consequence that system suppliers must invest in development to access IAM via messages on the ESB. In practice, too many preconditions and extra development trajectories are being created when opting for an ESB as an IAM solution.

Weich’s preferred solution is instead a separate identity manager, which he says can be considered a specialized variety of ESB, with access to an identity vault as described above. The one problem I can think of with this approach is that if I’m a cyber crook, I have only one place I need to spear-phish my way into in order to cause all sorts of damage: that identity vault.

For Wiech’s piece at Manufacturing Business Technology Magazine, click here.

Share This

Related Posts