Waarom Identity Management met ESB niet lukt

Door: Arnout van der Vorst

22 oktober 2013

Product en technologie

Het vakgebied Identity & Access Management (IAM) wordt steeds belangrijker binnen organisaties. Ook de inzet van de Enterprise Service Bus (ESB) neemt een vlucht. Ik krijg geregeld de vraag of de ESB niet ingezet kan worden voor het uitvoeren van Identity Management taken, zoals het aanmaken van user accounts, wijziging van een naam of functie van een medewerker.

De ESB lijkt in eerste instantie inderdaad een ideaal mechanisme voor het beheren van de verschillende digitale verschijningsvormen (= identities) van een natuurlijk persoon in het netwerk. Wanneer in een HR-systeem een medewerkers wordt opgevoerd, gaat er een signaal naar de ESB. Deze stuurt vervolgens real-time een bericht naar de Active Directory en het user account wordt aangemaakt. Omdat deze actie real-time is (in tegenstelling tot batchgewijs bij identity management), is dit ideaal voor commerciële organisaties waarbij users bijvoorbeeld direct een bestelling kunnen plaatsen nadat hun account is aangemaakt. De ESB werkt volgens een puur model waarbij de aangesloten applicaties ‘subscribed’ zijn op de ESB die diverse berichten ‘published’.

Toch is het in de praktijk anders. Daarvoor zijn een aantal oorzaken aan te wijzen:

Bi-directionele interface

De ESB is van nature een push/pull mechanisme, waarbij van aangesloten systemen altijd een bi-directionele interface wordt verwacht. Een ESB vereist dus dat alle applicaties 100 procent dekking bieden in het leveren van IAM-gerelateerde gegevens. We zien dat applicaties voor bijvoorbeeld voorraadbeheer of in de ERP-sector bijzonder goed zijn om deze gegevens via een ESB te ontsluiten. Voor IAM-gerelateerde gegevens schiet de ondersteuning hiervoor in de meeste gevallen te kort.

2. Identiteit sleutel

Wanneer het gaat om gebruikersgegevens heeft elke identiteit een externe-key (steutel) die in het bron/doelsysteem voorkomt. Als er met een ESB gewerkt wordt, moet deze externe-key altijd opgegeven worden bij een verzoek zodat het andere systeem de sleutel kan vertalen naar zijn eigen identiteiten. Omdat al deze sleutels ook over de bus gestuurd worden, wordt de ESB hiermee extra belast. Wil je de ESB inzetten dan is het nodig om een systeem hiernaast te onderhouden die de juiste sleutels mee kan leveren, bijvoorbeeld een Identity Vault.

Rapportages
Het gebruik van de ESB voor rapportages resulteert in een enorme belasting voor de ESB. Bij een ESB moeten meerdere verzoeken uitgezet worden op de ESB, waarbij de kennis van de externe-key voorhanden moet zijn. De ESB is daardoor voortdurend informatie aan verzoeken en berichten aan het rondpompen. Via een Identity Vault is deze informatie direct opvraagbaar.

Conclusie
In de praktijk zien we te veel randvoorwaarden en extra development-trajecten ontstaan bij de keuze voor een ESB als IAM-oplossing, een Identity Manager is dan de betere keuze.

Geschreven door:
Arnout van der Vorst

Maak kennis met Arnout van der Vorst, de inspirerende Identity Management Architect bij Tools4ever sinds het jaar 2000. Na zijn studie Hogere Informatica aan de Hogeschool van Utrecht is hij begonnen als Supportmedewerker bij Tools4ever. Daarna heeft Arnout zich opgewerkt tot een sleutelfiguur in het bedrijf. Zijn bijdragen strekken zich uit van klantondersteuning tot strategische pre-sales activiteiten, en hij deelt zijn kennis via webinars en artikelen.