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
Arnout,
Wat een heerlijk stuk, problematiek is zo herkenbaar en de pogingen om het op te lossen ook. Probleem is dat ‘EDI’ tussen applicaties die stukjes identity & access control informatie bevatten vooral moeilijk is omdat data niet genormaliseerd is. Zo mist aansluiting op de Excel sheet die HR bijhoudt, de CMDB van service desk en nog een stuk of wat bronnen die per afdeling gebruikt worden.
Nu biedt Microsoft, Quest en nog een handjevol leveranciers tegenwoordig heel goede mogelijkheden om de puzzel van een identiteit compleet te maken uit verschillende bronnen en via workflows dit ook compleet te houden, voor zowel de logische als fysieke toegang. En dat laatste voorkomt dat gedurende de lifecycle van een identiteit er meer rechten verkregen worden dan er voor een rol nodig is. Functionerende ESB-achtige ILM oplossing zijn er dus wel degelijk hoewel de volledige integratie ervan niet altijd politiek wenselijk wordt geacht.
Arnout,
Ik ben het met je eens: ESB is niet geschikt om te gebruiken als identity management systeem. De reden waarom dit zo is komt in mijn mening niet duidelijk tot uiting in jouw betoog.
Een identity management systeem bevat een eigen, centrale administratie van de identiteit van gebruikers en federaties en toegangsregels tot systemen, meestal met een middenlaag van rollen, attributen of andere regelstructuren. Een ESB is ‘slechts’ een berichtenbeheersysteem, wat berichten betrouwbaar van A naar B krijgt. Zo een centrale administratie lost ook meteen het probleem op wat jij beschrijft, dat de ene applicatie niet het datamodel van de andere applicatie kent. Dat hoeft niet, alle applicaties horen slechts gegevens uit de administratie op te vragen.
ESB kan wel deel uitmaken van een identity management systeem. Als de identity manager het platform van de applicatie ondersteund, hetzij met of zonder een eigen adapter (in feite de lokale agent van het identity management systeem op het platform), kan het best dat de ESB de communicatie verzorgd. Zoals je zelf al stelt: verwacht geen 100% dekking.
Een ander aspect wat in je betoog niet helder onderscheiden wordt is het gebruik van de identity management administratie als vraagbaak voor nadere gegevens (de telefoonboekfunctie) en het gebruik als beheerder van logische toegangsbeveiliging. Het eerste type gebruik vergt een directory waar vragen gesteld kunnen worden. Je merkt terecht op dat, wanneer hier een virtuele directory oplossing voor gebruikt wordt, de ESB een hogere belasting kent. Dit is een capaciteitsafweging die gemaakt moet worden. Het tweede type vergt een strak meet- en regelsysteem van adapters die provisioning (regelen) en reconciliation (meten) uitvoeren om te verzekeren dat toegangsbeveiliging op de aangesloten platformen goed geregeld is, of dit nu batchgewijs gaat of middels berichten over de ESB.
Concluderend zou ik je stelling iets willen aanpassen: ESB is niet geschikt om te gebruiken als identity management systeem, maar het kan prima gebruikt worden in de invulling ervan.
Dit is een duidelijk geval van hoe onderscheid je de goede architecten van de slechte. Een ESB gebruiken voor authenticatie is alsof je sleutels van je klanten met vrachtwagens gaat rondrijden terwijl je een fiets- of een beschooterde koerier wilt hebben die snel tussen het verkeer kan schieten omdat er haast bij is.
Authenticatie is een eigen ‘afdeling’ met eigen ‘standaarden’ en ‘regels’. Die zijn niet verzonnen omdat het zo leuk leek maar zijn ontstaan uit de praktijk. Als je daar aan houdt en er op een handig manier mee omgaat dan werkt het goed en blijft het werken.
Schakel desnoods de hulp in van gespecialiseerde IT bedrijven die dit soort werk dagelijks doen. Die kunnen je heel goed uitleggen wat je wel en niet kan doen en vooral waarom bepaalde ideeën niet werken in de praktijk.
Leuk artikel, er zijn te weinig artikelen over ESB terwijl het een interessant onderwerp is. Zelf ben ik nog niet op het idee gekomen om een ESB te gebruiken voor identity management. Een ander ding in deze lijkt me overigens ook concurrency aangezien de volgorde van het verwerken van berichten niet chronologisch is en daarnaast lijkt een ESB mij relatief te traag hiervoor.
Ik vind het onderwerp en de verdieping met voorbeelden precies op het juist niveau. Zo lees ik ze graag.
Overigens is IAM wel te realiseren als webservice.
Ben het eens met Lex. Een ESB is een doorgeefluik. Hiermee doe je geen “management” en dus ook geen “identity management”. Wel kan je het als onderdeel in een identity management oplossing prima inzetten voor het afhandelen en bewaken van de transacties en het eventueel rapporteren van statistieken daar over.
Overigens heb ik ook wel eens het tegenovergestelde gezien: een identity management oplossing die misbruikt werd als generieke integratie oplossing. MS FIM in dit geval. Dat was in ieder geval geen goed idee.
Goed om dit onderwerp hier eens onder de aandacht te brengen. Ik heb regelmatig discussies gehad met enterprise architecten van verschillende ondernemigen waar de bus vaak heilig is en alles over de bus moet gaan.
Ondanks dat er IdM systemen bestaan die realtime kunnen acteren het volgende; de bus verzorgt transport, over het algemeen nonpersistent. Belangrijkste ontbrekende factoren zijn inderdaad opslag (vault) en daarnaast de specifieke connectoren die IdM provisioning systemen vaak hebben. Deze vaak out of the box connectoren van een IdM systeem kunnen niet gebruikt worden, zodra er via een ESB gekoppeld gaat worden.
De ESB gebruiken voor IdM provisioning, maakt een project onnodig complex en kostbaar.
@Johan
Autorisatie begint met authenticatie, de onweerlegbaarheid van een digitale identiteit. Welke en hoe je rechten geeft aan zo’n identiteit is een beetje afhankelijk van de ondersteuning vanuit de applicatie/service. Role of Claim Based Access Control is namelijk vaak nog een utopie door legacy waardoor er vaak meerdere identity repositories ontstaan. SSO zit dus nog weleens met pleisters aan elkaar wat vervolgens de audit, het derde deel bemoeilijkt aangezien de onweerlegbaarheid niet altijd end-to-end is als gebruik gemaakt wordt van ‘proxy’ functionaliteiten.
@Gijs
Op grond van een aantal projecten concludeer ik dat gemiddeld genomen de vervuiling in de Active Directory, de user repository voor meeste Windows omgeving ongeveer 30% is. Dat levert niet alleen uitdagingen in de beveiliging op maar ook in de accounting bij bijvoorbeeld licenties of uitbesteding. Tellen is makkelijk maar correleren vaak moeilijk omdat sommige bronnen niet makkelijk informatie uitwisselen en juist dat was volgens mij ooit het idee van een ESB, ontsluiten van data.
Even voor de duidelijkheid, de ESB zorgt dus niet voor authenticatie of autorisatie maar voor het consistent houden van de verschillende bronnen, de bi-directionele uitwisseling zonder dat bronbeheerders gewijzigd hoeven te worden. FIM maakt het mogelijk om de puzzelstukjes te verzamelen waarbij de workflow gebruikt kan worden om niet alleen de aanmaak van een account te automatiseren maar ook de verwijdering als medewerker het bedrijf verlaat. Laatste wordt net als het afnemen van rechten als een medewerker een andere rol gaat vervullen namelijk nog weleens vergeten.
@Ewout goed verwoord.
Leuk om de reacties te lezen, de discussie die los komt laat zien dat het onderwerp leeft. Met zowel Ewout als Lex ben ik het eens, op dit moment probeer ik voor een lopend project de beste mix te vinden tussen IAM met een Identity Manager en het gebruik van de ESB.
Een ESB vind ik een prima transport-mechanisme om invulling te geven aan de wens om bepaalde IAM provisioning opdrachten “realtime” te laten uitvoeren. Ook de mogelijkheid om asynchroon opdrachten uit te zetten en de status op te kunnen vragen vind ik een interessante mogelijkheid van de ESB.
De balans waar we nu op uit komen is ongeveer als volgt:
– bronsysteem A kan enkel een “new identity” message op de ESB zetten met de sleutel van de nieuwe identiteit, op deze manier hoeft de leverancier van bronsysteem A geen volledige ESB connector te ontwikkelen
– de ESB stuurt dit bericht naar de Identity Manager
– de Identity Manager meldt terug aan de ESB dat de provisioning transactie is ontvangen
– de Identity Manager gaat zelf met een eigen connector terug naar bronsysteem A om de rest van de attributen en relaties van de nieuwe identiteit op te halen
– de Identity Manager voert provisioning opdrachten uit in doelsysteem B, C en D
– de Identity Manager legt in zijn eigen Vault een linked-keten aan van de identiteiten A, B, C en D
– de Identity Manager geeft een Ack bericht terug aan de ESB na het uitvoeren van de provisioning transactie
– de ESB kan de Identity Manager ondervragen om de linked-sleutels opvragen van bijvoorbeeld C, dan krijgt de ESB de sleutels voor A, B en D terug
– de ESB kan met de sleutels vervolgens de individuele doelsystemen ondervragen
Volgens mij gebruik je op deze manier de ESB voor “push-notificaties” en het “real-time” initiatief, en de Identity Manager voor de connectors, het beheer van de identiteiten (sleutels) en de business logica van de provisioning.
Arnout,
Hoewel je het generiek beschrijft krijg ik de indruk dat je nu alleen ‘onboarding’ dekt, als bron A bijvoorbeeld HR is dan zou deze naar mijn opinie ook een de-provisioning message op de bus moeten kunnen plaatsen:
http://www.it.ubc.ca/sites/it.ubc.ca/files/how_IAM_works9727.png