Dean Wiech joined Tools4ever in April 2006 and is responsible for the Tools4ever, Inc. operations the United States. His duties include direct sales as well as the responsibility for the sales, technology and consulting team along with the day-to-day operations for the company.
Dean has been involved with sales and sales management in the software arena for over 20 years – before joining Tools4ever he was Vice President of Sales for a Manhattan based Software Company that is specialized in cost allocation and spend optimization. He attended the University of Akron and studied Chemical Engineering before deciding to pursue a career in technology.
Identity Management and Enterprise Service Bus a Happy Marriage Does Not Make Published: December 2, 2014 • Service Technology Magazine Issue LXXXVII PDF
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 or 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.
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.
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. That results in an enormous burden on the network, because this information always has to be sent during identity management activities.
With an identity manager, this type of ID information is normally stored in a so-called identity vault, one central data store with all personnel details and user IDs. The identity vault is populated with information from various sources, such as an HR system, for instance, or roster planning, management, the Active Directory, or a facility management system. The information might constitute name and address details, contract details, office number, job title, cost center, manager, and resources issued, such as a telephone or access card. If you want to deploy the ESB for user data, then it's necessary to maintain a system in tandem, which can deliver the right keys; for example, an identity vault, easily and without placing any significant burden on the network.
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.
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.
Another important advantage of using an identity vault rather than an ESB is that the identity vault is extremely suitable for a self-service environment. Self-service portals within organizations are hot items. From experience in their personal lives, employees are used to being able to request things themselves, for example arranging insurance. Now they also expect that functionality in their work environment. Consider, for example, the ability to request rights within an application yourself, or access to a share, or a license for a particular application. Many organizations provide a self-service portal for their staff, through which they can easy conduct these types of transaction. To be able to send these requests automatically to those in charge of the applicants, or to the owner (e.g. the license manager), it's necessary to have an insight into the organizational structure. Through established workflows the requests can then be presented to the responsible person for approval. And if that responsible person does not respond, or does not respond in good time, the request can then be forwarded to a responsible person higher up the ladder.
As indicated earlier, an ESB does not store any data. That includes any information about organizational structure, including the relationships between employees and managers. So to facilitate self-service, an identity vault is thus a must.
An ESB also does not record which authorizations employees have, and which authorizations employees should have. In an identity vault, all authorizations in the network are scanned, stored and made searchable. This provides a full picture of who someone is, what he may do and what he has. A standard or norm can be set for each role or job, so that the minimum authorization someone needs in a particular job becomes clear. Once an employee is not included in the core records, he cannot access the network, and thus cannot access important information. Because the data in the identity vault is searchable, the security officer can search for an individual and then see immediately which systems that person occurs in, under which identities, and all the things that person may do. Per department or team, the security officer can also see just who is using which rights, so that divergences can quickly be spotted. In this way an organization can easily comply with internal and external audits, and with regulations and legislation.
Identity management with the ESB is a 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.