The subject of identity and access management (IAM) is becoming increasingly important within organizations. Where previously IAM was linked to user lifecycle management on the basis of provisioning, there’s currently a move in which many more components and focus points are gathered under the IAM flag, such as core registration, multifactor authentication, role-based access and self-service workflows. Deployment of the enterprise service bus (ESB) is also expanding significantly. In particular, local system owners are using the ESB more frequently to send and receive messages between systems in real time.
When asked whether ESB can be deployed to carry out a variety of identity management activities, like creating user accounts or changing the name or position of an employee, 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; however, things work differently in practice, and there are a number of reasons why it is not ideal.
Bi-directional interface
Intrinsically, the ESB is a push/pull mechanism, where a bi-directional interface is always expected from the connected systems. This means all source and target systems must be connected to the ESB and the applications themselves must be able to recognize all changes internally and to deliver this as a message on the bus. Traditionally, ESB was primarily used in the ERP sector and there were no problems associated with this. After all similar information, such as stock control and lot codes, were sent over the bus and the connected applications had no difficulty in reading and processing this type of message.
However, the type of data related to identity management is very different. What’s involved may be a change in job or surname, or a promotion or departure of employees. Often the applications cannot read this type of information by default, and it requires considerable developmental work on the part of the application supplier to enable this. Additionally, there is only basic support for the sending of messages; for example, only in the case of a new identity. At the same time, other systems are involved in identity management other than the “normal” ones from the ERP sector, such as HRM systems, facilitative and electronic client dossiers. At the moment these applications do not have an ESB connector.
Identity key
As far as user systems are concerned, each identity has an external key that occurs in the source/target system. If an ESB is being used, this external key must always be provided with a request so that the other system can translate the key into its own identities. Suppose you have an identity in system “A” called “ID 123.” From this identity you want to check whether a record already exists in system B. You can only do this if system “B” recognizes the key (ID 123) of system “A” or if you know the key of system “B” during the ESB request. Since all these keys are also sent via the bus, the ESB also has to bear an extra burden.
With an identity manager, this type of ID information is normally stored in an identity vault - one central data store that has all personnel details and user IDs. To introduce the ESB it is necessary to maintain a system alongside this which can provide the correct keys, such as an identity vault.
ESB non-persistent
The ESB is non-persistent and, thus, does not retain data. It only carries out the retrieval and delivery of data. If you only work with an ESB there is no database where information about external employees is maintained, and these employees are not recorded in the HR system. With identity management, once again, the identity vault is utilized for this.
Reports
Using the ESB for reports places an enormous burden on it. Suppose that from system “A” you want to have the pass number for an identity, from system “B” the e-mail address of the identity, and a telephone number from system “C.” With an ESB multiple requests must be sent where knowledge of the external key must be available. The ESB is thus constantly occupied in requesting information and sending out messages. Through an identity vault this information is immediately requestable.
Conclusion
Identity management with the ESB is an utopian ideal. In architectural terms it is impressive, but it is not yet achievable in practice. An identity manager can be regarded as a sort of specialized ESB, combined with the storage of information, intelligence to interpret the delivered data and business rules for provisioning tasks. 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. Therefore, an identity management system is then the better choice overall.
Dean Wiech is managing director of Tools4ever, a global provider of identity and access management solutions.
To read more manufacturing and technology news, sign up for our newsletter. You can also follow Manufacturing Business Technology on Twitter @MBTwebsite.
