Independent. Dynamic. Involved.
nlen

De voorwaarden voor gebruik van IDaaS

Door John van Westeneng

Identity as a Service, of IDaaS, zorgt voor een verandering in de huidige Identity en Access Management markt.

Veelal, vooral Enterprise organisaties hebben de laatste 10 jaar identity en access management oplossingen geïmplementeerd met een vooral technische invalshoek. Volledig opmaat, waarbij zowel standaard als legacy applicaties zijn aangesloten. Vaak, bij een goede en gelukte implementatie, is de gebruikers lifecycle volledig geautomatiseerd. Meestal in samenwerking met een HRM systeem. Daarnaast is het koppelvlak naar IT gemaakt en zijn de account en autorisatie lifecycle geheel of gedeeltelijk onder controle.

Door de hoge mate van maatwerk en integratie zijn dit langlopende, hoog risico en daardoor relatief dure implementaties. Hierdoor, en de adoptie van Software As a Service (SAAS), waarmee organisaties aantoonbaar bewijzen dat ze willen en kunnen standaardiseren, zijn er diverse IDaaS leveranciers die een gedeelte (!) van de identity en access management maatwerk oplossing kunnen standaardiseren.

Erg mooi, maar wat betekent dat nu eigenlijk? Wat moet je als organisatie toch nog steeds wel inregelen? En waar liggen dan als nog de hoge risico’s die zeker gemitigeerd moeten worden?

IDaaS leveranciers leveren eind 2014 diensten en services die zich primair richten op authenticatie en het leveren van single sign-on naar cloud en on-premise applicaties. Daarnaast leveren deze leveranciers course grained autorisatie management en zeer beperkte provisioning functionaliteit. Reden hiervoor komt voort uit het feit dat de aan te sluiten applicaties, zowel voor authenticatie als provisioning, niet of nauwelijks de betreffende industrie standaarden ondersteunen (SAML/OpenID Connect/Oauth 2.0 en SCIM). Uit de ervaring cijfers blijkt dat ongeveer 10% van de cloud applicaties SAML ondersteund, ongeveer 400 tot 500. Slechts 10 tot 15 van de cloud applicaties beschikbaar in de catalogus van bijvoorbeeld OKTA en Microsoft ondersteunt provisioning via APIs. Hoeveel van de on-premise, specifiek business applicaties, ondersteunen deze standaarden? Zijn klaar om bijvoorbeeld via SAML of een van de andere standaarden hun gebruikers te kunnen authenticeren? Mijn ervaring, weinig. En ombouwen is ook niet ‘zomaar’ even gedaan gezien het legacy aspect van veel van deze applicaties.

Wat betreft provisioning gaat het helemaal nog niet de goede kant op. Autorisatie management is in zijn geheel nog niet te automatiseren hierdoor. De ‘Ben Ik In Control’ vraag ga ik niet eens op in…

IDaaS gaat succesvol zijn en de klassieke variant kunnen vervangen wanneer organisaties, zowel de cloud leveranciers als de gebruikers (dwz. de enterprises) hiervan, hun applicatielandschap aan een aantal principes gaan laten voldoen. Hieronder een opsomming:

1. Voor authenticatie wordt gebruik gemaakt van een federatief model waar de authenticatie service is gecentraliseerd of in ieder geval buiten de applicatie zelf ligt. Er wordt gebruik gemaakt van standaarden als SAML, OpenID Connect en/of OAUTH 2.0.

2. Voor provisioning wordt gebruik gemaakt van APIs die alleen over een veilige verbinding, geauthentiseerd, kunnen worden aangesproken. Een standaard als SCIM heeft de voorkeur, REST is minimaal vereist.

3. Voor autorisatie management wordt gebruik gemaakt van een attribuut gebaseerd toegangsmodel. Vanuit de authenticatie service wordt op basis van geleverde attributen in de applicatie bepaald wat de gebruiker mag.

4. Voor autorisatie bepaling of besluitvorming rondom toegang (policy decision) kan centraal worden bepaald en wordt vanuit dit centrale punt gedistribueerd.

5. Audit trials zijn op een veilige manier toegankelijk. Standaarden voor de uitwisseling van deze audit trials zijn in ontwikkeling. Naar mate bandbreedte geen issue is, wordt het mogelijk om audit trials ongefilterd te lezen vanuit applicatie omgevingen.

Een ander zorg punt is de business kant. Een IAM implementatie is namelijk een verander project. Lifecycle processen die op basis van bron informatie worden geautomatiseerd, worden veranderd. Processen waar eindgebruikers zelf toegangsrechten kunnen aanvragen worden geïntroduceerd. Daarnaast vraagt dit van de organisatie om deze processen te kunnen ondersteunen, vraagt het om een bepaalde governance binnen de organisatie, bijvoorbeeld het antwoord op de vraag, wie is verantwoordelijk voor de autorisatie van een gebruiker? Wanneer dit niet of onvoldoende is geïmplementeerd moet dit worden veranderd. En dat… raakt de gehele organisatie. Compliance is ook een aspect wat hierin een aandachtspunt is. Wanneer een organisatie dit namelijk niet op orde heeft, moet ook dit veranderen en deze verandering moet worden embed in de organisatie en haar applicaties.
Een IAM implementatie is daarom een echt verander project. En verandering succesvol doorvoeren is moeilijk. In iedere organisatie.

IDaaS gaat daar geen verandering in brengen. Sterker, IDaaS dwingt verandering af doordat een aantal starre identity gerelateerde processen worden geïntroduceerd. Met daarbij de nadruk op star.

Het is in de huidige stand van de IDaaS technologie niet of nauwelijks mogelijk om maatwerk hierin te leveren. Organisaties die met IDaaS aan de slag gaan, gaan of met een beperkte scope aan de slag, bijvoorbeeld alleen authenticatie, of passen zich aan de beperkte processen in een dergelijk IDaaS omgeving en dat laatste is een verander project op zich wat veel van de IDaaS voordelen te niet doen.

De (voorlopige) oplossing? Hybride identity en access management omgevingen?

Hybride identity en access management oplossingen zijn voorlopig de oplossing voor dit probleem. Een organisatie die IDaaS inzet is sneller wat betreft het neerzetten van het zogenaamde (Authenticatie) fundament. Daarna valt het terug in klassiek aansluiten van applicaties, embedden van de meegeleverde IDaaS processen, etc. In het hybride model wordt een deel van de provisioning en autorisatie management on-premise door tooling als RSA Aveksa of Omada uitgevoerd. Vanuit een koppelvlak, bijvoorbeeld een Active Directory, is de IDaaS voorziening aangesloten. Waarbij deze laatste primair verantwoordelijk is voor het leveren van de authenticatie services. Saillant detail is dat Microsoft de on-premise Active Directory aan het verplaatsen is naar de IDaaS omgeving Azure Active Directory. Hierdoor wordt het koppelvlak onderdeel van de IDaaS.

Wanneer u meer wilt weten over IDaaS, wat het kan betekenen voor uw organisatie en onze ervaringen, neem dan contact met ons op. Wij gaan graag in gesprek met u.