Het vakgebied identity & access management (iam) wordt steeds belangrijker binnen organisaties. Waar voorheen iam vaak werd verbonden met user lifecycle management op basis van provisioning, zien we tegenwoordig veel meer onderdelen en aandachtspunten onder de iam vlag vallen, zoals kernregistratie, multi-factor authenticatie, role based access, self-service workflows. Ook de inzet van de enterprise service bus (esb) neemt een vlucht. Met name bij lokale overheden wordt de esb steeds vaker ingezet voor het real-time versturen en ontvangen van messages tussen systemen.
Ik krijg geregeld de vraag of de esb niet ingezet kan worden voor het uitvoeren van diverse identity management activiteiten, zoals het aanmaken van user accounts, wijzigingen van een naam of functie van een medewerkers.
De esb lijkt 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. Denk bijvoorbeeld aan een webshop of aanbieder van cursussen. De esb werkt volgens een puur model waarbij de aangesloten applicaties ‘subscribed’ zijn op de esb en deze diverse berichten ‘published’.
Tot zover lijkt de esb ideaal voor het beheren van identiteiten in het netwerk. Toch werkt het in de praktijk anders en werkt mijns inziens de enterprise service bus niet bij het beheren van identiteiten in het netwerk. 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. Alle bron- en doelsystemen moeten dus op de esb aangesloten worden en de applicaties moeten zelf in staat zijn om (alle) mutaties intern te herkennen en dit als message op de bus te leveren. Omdat de esb van oudsher vooral veel gebruikt werd in de erp-sector, gaf dat voorheen geen problemen. Er werden immers gelijksoortige informatie (bijvoorbeeld over voorraadbeheer, lotcodes) over de bus heen gestuurd. De aangesloten applicaties hadden geen moeite om de type berichten te lezen en te verwerken.
De type data gerelateerd aan identity management is echter heel verschillend. Zo kan het een wijziging in functie, achternaam of in-, door- en uitstroom van medewerkers betreffen. Vaak kunnen de applicaties deze type informatie standaard niet lezen en eist het nog veel ontwikkelwerk van de applicatieleverancier om dit wel te kunnen. Of er geldt slechts basis ondersteuning voor het sturen van messages, bijvoorbeeld alleen bij een nieuwe identiteit. Daarnaast zijn bij identity management andere systemen betrokken dan de ‘normale’ systemen uit de erp-sector, zoals hrm-systemen, facilitair en elektronische cliëntendossier. Deze applicaties hebben op dit moment geen esb-connector.
Identiteit sleutel
Wanneer het gaat om gebruikersgegevens heeft elke identiteit heeft 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. Stel dat je een identiteit in systeem A hebt met ‘ID 123’. Van deze identiteit wil je controleren of er in systeem B al een record bestaat. Je kunt dit alleen doen als systeem B de sleutel (‘ID 123’) van systeem A kent, of als je de key van systeem B weet bij de esb-aanvraag. Omdat al deze sleutels ook over de bus gestuurd worden, wordt de esb hiermee extra belast.
Bij een identity manager wordt dit soort id-informatie gewoonlijk opgeslagen in een identity vault, één centraal gegevensmagazijn met alle personeelsgegevens en user-id’s. 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.
Esb niet-persistent
De esb is niet-persistent en houdt dus geen gegevens vast. Het verzorgt alleen het ophalen en de levering van gegevens. Wanneer er alleen gewerkt wordt met een esb is er feitelijk geen database waar informatie over externe medewerkers wordt bijgehouden. Deze medewerkers staan immers ook niet in het hr-systeem. Bij identity management wordt hier wederom de identity vault voor ingezet.
Rapportages
Het gebruik van de esb voor rapportages resulteert in een enorme belasting voor de esb. Stel bijvoorbeeld dat je uit systeem A een pasnummer van een identiteit wilt weten en uit systeem B het e-mailadres van de identiteit en een telefoonnummer uit systeem C. 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
Identity management met de enterprise service bus is een utopie. Qua architectuur is het prachtig, maar in de praktijk niet haalbaar. Een identity manager kan gezien worden als een soort gespecialiseerde esb, gecombineerd met opslag van informatie, intelligentie om aangeleverde data te interpreteren en business rules voor provisioning opdrachten. Een esb vereist 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. De strategische keuze voor een esb heeft dan als gevolg dat de leveranciers van systemen moeten investeren in ontwikkeling om iam-gegevens te ontsluiten via messages op de esb. 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.
Arnout van der Vorst, managing ICT consultant bij Tools4ever en expert in Identity & Access Management
@Ewout: klopt, dit is alleen voor de instroom. De rest van de lifecycle gaan we door de Identity Manager zelf laten afhandelen met directe connectors naar de bron/doelsystemen. De ESB kan hooguit een signalering afgeven bij een ontslag op staande voet waarbij de Identity Manager vervolgens kan acteren. Een “normale” deprovisioning wordt door de Identity Manager via een scheduled proces enkele malen per dag opgevangen, in veel gevallen is dit voldoende zonder initiatief van de ESB.