Eindrapport Identity as a Service

Transcriptie

1 indi Eindrapport Identity as a Service Project : SURFworks Projectjaar : 2009 Projectmanager : Remco Poortinga, Roland van Rijswijk Auteur(s) : Peter Jurg, Arjo duineveld Opleverdatum : Versie : 1.0 Samenvatting Dit document beschrijft de resultaten van de Proof of Concept van Identity as a Service. Deel hiervan is een beschrijving van het geïmplementeerde systeem en een business case voor IaaS. 1

2 Colofon Programmalijn : Proof of Concept Onderdeel : SURFfederatie: IaaS Activiteit : Deliverable : Eindrapport PoC SURFfederatie IaaS Toegangsrechten : publiek Externe partij : IGI Group Dit project is tot stand gekomen met steun van SURF, de organisatie die ICT vernieuwingen in het hoger onderwijs en onderzoek initieert, regisseert en stimuleert door onder meer het financieren van projecten. Meer informatie over SURF is te vinden op de website ( 2

3 Context 6 dingen die je moet weten over Eindrapport IaaS In het kader van het SURFworks programma is een onderzoek uitgevoerd naar Identiy-as-a-Service. Deel van dit onderzoek was het uitvoeren van een proofof-concept, dit rapport gaat over de resultaten daarvan. Wat is het? Identity-as-a-Service is een identity management oplossing als kant-en-klare dienst. Dit rapport beschrijft hoe zo n dienst kan functioneren en hoe instellingen hier tegenaan kijken. Voor wie is het? Instellingen die geïnteresseerd zijn in identity management en specifiek in Identity-as-a-Service Hoe werkt het? IaaS werkt met een extern identity management systeem dat bijvoorbeeld in de cloud staat, wat het mogelijk makt op basis van gestandaardiseerde processen voor het beheer van account life-cycles snel identity management in te voeren in een organisatie. Wat kan je ermee? Met IaaS kun je op een kosteneffectieve manier snel identity management invoeren met zo min mogelijk maatwerk. Extra (Bijlagen, Thema, Gerelateerde thema s) N.v.t. 3

4 Versiebeheer Datum Door Wijzigingen Peter, Arjo Initieel Peter, Arjo Toevoegingen en verbeteringen Peter, Arjo Business case en conclusies toegevoegd Arjo Bevindingen toegevoegd, review commentaar verwerkt Arjo Commentaar van Peter verwerkt, voorbladen toegevoegd. 4

5 Inhoud 1. Inleiding Doel van de Proof of Concept Verloop van de Proof of Concept Leeswijzer Werkwijze Statusdiagrammen Processen Implementatie Architectuur IGI-NDSTREE Delimited Text test User Application Loopback Role and Resource Service LDAP target Test federatie Systeemoverzicht Bevindingen Standaard, configureerbaar en maatwerk Bron- en doelsystemen Redenen voor deactivering Beheeraccounts Standaard functionaliteit Bevindingen van de instellingen Christelijke Hogeschool Ede Radboud Universiteit Business case Conclusie

6 1. Inleiding 1.1. Doel van de Proof of Concept In de technologieverkenningen van SURFnet voor het jaar 2009 is een Proof of Concept Identity-as-a- Service opgenomen. Met Identity-as-a-Service (IaaS) wordt beoogd dat instellingen, en met name de wat kleinere, binnen de doelgroep gebruik kunnen maken van een klaarstaande online Identity Management (IdM) service. De instelling voert dan alleen nog maar functioneel beheer uit. De service presenteert zich naar de instelling als een eigen identity management systeem, gestandaardiseerd en met beperkte, nader te bepalen, configuratie- en koppelingsopties. In het document Onderzoek naar het realiseren van Identity as a Service voor SURFnet: Identity as a Service, Requirements en Haalbaarheidsrapportage is aangegeven dat een Proof of Concept (PoC) antwoord kan geven op de vraag of een IaaS-dienst levensvatbaar is, het belangrijkste resultaat van het IaaS-traject. Daarmee is een positief advies gegeven voor het uitvoeren van een PoC. Dit advies is opgevolgd door SURFnet en in het najaar van 2009 is een PoC uitgevoerd door IGI Group. Dit document is het eindrapport over de PoC. Het geeft antwoord op de vraag of IaaS een dienst kan worden die levensvatbaar is. Om deze vraag positief te beantwoorden moet het systeem aan een aantal voorwaarden voldoen: Een standaarddienst waarop instellingen hun processen rondom het uitdelen, wijzigen en intrekken van accounts en rechten zonder veel problemen kunnen aanpassen. De rechten betreffen ook rechten op federatieve diensten. Een dienst die in technische zin voldoende configureerbaar is om aan te sluiten bij de bestaande bronsystemen, authenticatiedatabases en andere doelsystemen die een instelling al heeft. Een dienst die betaalbaar is voor kleinere instellingen Verloop van de Proof of Concept De functionaliteit en architectuur van IaaS zijn beschreven in hoofdstuk 2 van de bovengenoemde haalbaarheidsrapportage. De functionaliteit was onvoldoende expliciet gemaakt om goed inzicht te krijgen in de processen voor identity management die IaaS zou implementeren. Deze processen zijn daarom in de PoC verder uitgewerkt. De uitgewerkte processen zijn tevens gebruikt om bij twee hoger onderwijsinstellingen na te gaan of zij hiermee uit de voeten zouden kunnen. De PoC is ook gedemonstreerd aan deze instellingen, waarmee een antwoord kan worden gegeven op de vraag of deze dienst een oplossing zou kunnen zijn voor hun identity managementproblematiek. De instellingen zijn de Christelijke Hogeschool Ede (CHE) en de Radboud Universiteit. De eerste heeft nog geen identity management ingericht, de tweede heeft daar al enkele jaren ervaring mee. Beide instellingen zijn overigens wel aangesloten op de SURFfederatie. Behalve door de instellingen zijn de procesbeschrijvingen en de demonstratie ook kritisch bekeken door SURFnet. Daar zijn verbeteringen uit voort gekomen ten aanzien van de processen en de flexibiliteit van de demonstratieomgeving (configureerbaarheid). De PoC heeft dus geholpen om de eerste twee van de bovenstaande vragen te beantwoorden die de levensvatbaarheid van de dienst moeten aangeven. Maar tegelijkertijd heeft de PoC informatie opgeleverd over de kosten die aan IaaS verbonden zijn, doordat beter duidelijk is geworden welke 6

7 standaard voorzieningen, te configureren voorzieningen en maatwerk voorzieningen geleverd moeten worden. Ook is inzicht verkregen in de benodigde hard- en software. De PoC is uitgevoerd in samenwerking met Novell, die haar software ter beschikking heeft gesteld Leeswijzer In het volgende hoofdstuk wordt aangegeven welke werkwijze is gehanteerd bij de bouw van de PoC. Daarbij wordt ingegaan op de aard van de procesbeschrijvingen. In hoofdstuk 3 wordt de architectuur van de PoC beschreven, zoals die met de Novell software is gerealiseerd. In hoofdstuk 4 wordt de functionaliteit van de processen geïllustreerd door met screenshots aan te geven hoe de Novellsoftware werkt. In hoofdstuk 5 worden de bevindingen weergegeven. Deze betreffen zowel de techniek (wat is standaard, wat moet configureerbaar zijn, wat is maatwerk en is daar een goed evenwicht in te vinden) als de bevindingen van de twee instellingen die dit traject hebben gereviewed. In hoofdstuk 6 wordt een indicatie gegeven van de kosten van IaaS. Hoofdstuk 7, tenslotte, bevat kort de conclusies die volgen uit de bevindingen. Voor het begrip van IaaS is het aan te bevelen de haalbaarheidsstudie voorafgaand aan dit eindrapport te lezen. 7

8 2. Werkwijze Voor het realiseren van de Proof of Concept (PoC) hebben de volgende activiteiten plaatsgevonden: In statusdiagrammen zijn de life cycles van de verschillende types accounts beschreven. De processen die een rol spelen binnen de life cycle zijn beschreven. Aan de hand van deze processen is de life cycle binnen Novell Identity Manager geïmplementeerd. Elk van deze activiteiten wordt hieronder nader toegelicht. Voor de uitwerkingen van de statusdiagrammen en processen wordt u verwezen naar het procesbeschrijvingendocument dat eerder is opgeleverd Statusdiagrammen Voor de verschillende typen accounts (Medewerkers, scholieren, vooraanmelders, studenten, alumni en accounts voor externen) is de lifecycle beschreven in een statusdiagram. In zo n diagram zijn de verschillende statussen te zien waarin een account zich kan bevinden met de overgangen die er tussen de verschillende statussen mogelijk zijn. Elk van deze statusovergangen (pijlen in het diagram) correspondeert met een proces. Afbeelding 1 toont een voorbeeld van een dergelijk diagram. Deze activiteit is uitgevoerd voor alle 6, bovengenoemde, typen accounts. Afbeelding 1 Statusdiagram voor medewerker accounts 2.2. Processen Alle pijlen uit de statusdiagrammen zijn beschreven in een procesbeschrijving. Zo n procesbeschrijving bestaat uit drie delen: Een functionele beschrijving. Beschrijft wat er gebeurt tijdens een proces 8

9 Een functionele flowchart. Een diagram dat opgedeeld is een aantal kolommen die corresponderen met verschillende systemen. Bijvoorbeeld de bronsystemen, de Identity Vault (een systeem dat geconsolideerde informatie over identiteiten bevat) en de doelsystemen. Een flowchart beschrijft de verschillende stappen in het proces en in welke volgorde deze stappen plaatsvinden. De verschillende blokken in de flowchart zijn geplaatst in de kolom van het systeem waarin de stap plaatsvindt. Een procesbeschrijving. Beschrijft de stappen die ook al in het diagram voorkomen gedetailleerder. Net als de statusdiagrammen zijn deze processen uitgewerkt voor alle typen accounts Implementatie Om een werkend systeem te kunnen demonstreren is een deel van de processen geïmplementeerd. Dit betreft de processen die betrekking hebben op een studentenaccount en de processen die betrekking hebben op een account voor een externe. Met andere woorden: alle processen die betrekking hebben op medewerkers, scholieren en vooraanmelders zijn niet geïmplementeerd. Deze processen zijn vergelijkbaar met de processen die wel geïmplementeerd zijn dus het voegt voor de PoC niets toe om deze processen te implementeren. De functionaliteit die geïmplementeerd is wordt in hoofdstuk 4 gedetailleerder beschreven. 9

10 3. Architectuur Dit hoofdstuk beschrijft de architectuur van het systeem dat gemaakt is om een werkend systeem te kunnen demonstreren. Het systeem is geïmplementeerd in Novell Identity Manager. De ontwikkel tool die daarbij hoort heet Designer voor Novell Identity Manager. Deze toont de verschillende onderdelen van het systeem. Afbeelding 1 toont de systeemarchitectuur zoals die door Designer wordt weergegeven, aangevuld met een representatie van de testfederatie die tegen de LDAP server authenticeert. Afbeelding 2 Architectuur van de implementatie Er zijn dus de volgende onderdelen te onderscheiden: IGI-NDSTREE. Delimited Text test. User Application. Loopback. Role and Resource Service. LDAP target. Test federatie. Elk van deze onderdelen (behalve IGI-NDSTREE en de testfederatie) is een driver binnen Identity Manager. Een driver verzorgt in principe de provisioning (en deprovisioning) van en naar een extern systeem. Voor de Delimited Text test en LDAP target klopt dit, de User Application en Role and 10

11 Resource Service en Loopback zijn uitzonderingen op de normale drivers. Hieronder worden de verschillende onderdelen nader toegelicht. Daarbij komt ook de uitzonderingspositie van deze 3 drivers aan de orde IGI-NDSTREE Dit is de centrale opslag voor (geconsolideerde) accountgegevens, ofwel Identity Vault. De verschillende drivers van het systeem wijzigen of gebruiken de informatie die in de Identity Vault is opgeslagen Delimited Text test Deze driver leest een bestand met door komma s gescheiden waarden (comma separated values of.csv file) in en creëert accounts op basis van de gegevens die in de.csv file staan. De accounts die worden gemaakt zijn studentenaccounts. Deze driver simuleert dus de driver die in een productiesysteem de gegevens uit het Studenten Informatie Systeem (SIS) binnenhaalt en in de Identity Vault plaatst. De keuze om voor de PoC een gesimuleerd bronsysteem te gebruiken is gemaakt om de demo eenvoudig te houden. Hierdoor hoeft geen SIS te worden geïnstalleerd en gevuld met testgegevens. In een productiesysteem zal het koppelen van bronsystemen altijd maatwerk blijven en de inschatting hoeveel tijd het kost zal afhangen van een aantal factoren. De tijdsinspanning die het gekost zou hebben om in de PoC een SIS aan te lsuiten zou dus niet representatief zijn geweest User Application Deze driver verzorgt geen koppeling met een extern systeem maar zorgt voor de gegevensuitwisseling met alle schermen van de gebruikersinterface (voor beheerders) van het identity managementsysteem. Er is bijvoorbeeld een scherm waarin een account voor een externe kan worden aangemaakt. De User Application Driver zorgt ervoor dat dit nieuwe account ook daadwerkelijk in de Identity Vault wordt geplaatst Loopback De Loopback driver verzorgt geen koppeling met een extern systeem maar bevat logica die gegevens van een bepaald account aanpast op basis van andere gegevens van die account. Denk daarbij bijvooorbeeld aan regels als Als het wachtwoord is gewijzigd moet de status van het account worden gewijzigd in actief of Als een gebruiker een activeringscode heeft ontvangen moet zijn wachtwoord worden ingesteld op de nieuwe activeringscode (zodat de gebruiker met zijn activeringscode kan inloggen) Role and Resource Service Op het moment dat de User Application driver wordt toegevoegd aan het systeem wordt de Role and Resource Service automatisch ook toegevoegd. Deze driver kan, zoals de naam al aangeeft, zaken met 11

12 betrekking tot Role based access regelen. Omdat er van die functionaliteit geen gebruik gemaakt wordt, wordt deze driver ook niet gebruikt LDAP target Deze driver zorgt ervoor dat accountgegevens worden doorgegeven aan een LDAP server. In de driver zit logica over welke accounts wel en welke accounts niet als actieve accounts in LDAP terecht moeten komen. Dit wordt bepaald op basis van de status van het account. Dit systeem is een voorbeeld doelsysteem waarnaar het IDM-systeem provisioning doet Test federatie Op de test federatie is een Identity provider aangemaakt die de LDAP server die verbonden is met het IaaS PoC systeem gebruikt om tegen te authenticeren. Zo kan getoond worden dat iemand met een actieve account in de Identity Vault kan inloggen op de test federatie en iemand met een inactieve account niet kan inloggen. 12

13 4. Systeemoverzicht In dit hoofdstuk wordt aan de hand van screenshots getoond wat het IaaS PoC systeem aan functionaliteit biedt. Onder elk scherm is een toelichting op de afbeelding te vinden. Afbeelding 3 Het login scherm van Identity Manager van Novell In het standaard aanmeldscherm van Novell Identity Manager wordt hier ingelogd als IaaSExternAdmin. Er zijn voor de PoC twee beheerdersaccounts aangemaakt. Naast de IaaSExternAdmin is er nog IaaSStudentAdmin. De eerste kan alle zaken die met accounts voor externen te maken hebben beheren. De tweede kan alle zaken die met studenten te maken hebben beheren. Dit demonstreert de mogelijkheid om deze beheertaken te scheiden. 13

14 Afbeelding 4 Ingelogd als Admin van accounts voor externen Na inloggen als beheerder (van externe accounts) verschijnt dit scherm. Links het menu met alle mogelijkheden die een beheerder van accounts voor externen heeft. Naast het wijzigen van het wachtwoord (wat een gewone gebruiker ook kan) zijn dat: Het aanmaken van een account. Een activeringscode aanmaken en instellen voor een account. Het deactiveren van een account. Het heractiveren van een account. De mogelijkheid om een account te verwijderen (die wel te vinden is in de uitgewerkte processen) is niet geïmplementeerd in het PoC systeem. Dit geldt ook voor de mogelijkheid om een wachtwoord te resetten. 14

15 Afbeelding 5 Aanmaken van een nieuwe account voor een externe Dit scherm toont de interface om een nieuwe account aan te maken. Er moeten een aantal basisgegevens worden ingevoerd. Op basis van de voor- en achternaam wordt een username gegeneerd in dit geval jdoe. Dus de eerste letter van de voornaam gecombineerd met de achternaam. Als deze gebruikersnaam al bestaat wordt een volgnummer toegevoegd, bijv jdoe1. 15

16 Afbeelding 6 Een account voor een externe een activeringscode geven Om de nieuwe account een activeringscode te geven klikt de beheerder op de tweede optie. Hij krijgt dan dit scherm te zien. Er verschijnt een lijst met nieuwe accounts (in dit geval maar één account). Als één van de accounts geselecteerd wordt, wordt in het activeringscode veld een activeringscode getoond. In de PoC is dat altijd welkom1 in een productiesysteem zou dit een willekeurig gegenereerde en voor elke gebruiker andere code moeten zijn. Als op de knop Activeringscode wordt geklikt wordt de activeringscode ingesteld voor de gebruiker. Het is aan de beheerder die deze actie uitvoert om de activeringcode te communiceren aan John Doe. 16

17 Afbeelding 7 Inloggen als gebruiker John Doe kan nu, in het standaard inlogscherm, inloggen met zijn gebruikersnaam en activeringscode. 17

18 Afbeelding 8 Ingelogd als gebruiker Na het inloggen heeft hij maar één menuoptie: het wijzigen van zijn wachtwoord. Hij vult zijn activeringscode in als huidig wachtwoord en stelt een zelfgekozen wachtwoord in. 18

19 Afbeelding 9 Gebruiker heeft zijn wachtwoord gewijzigd Als hij deze stap heeft uitgevoerd wordt zijn account actief in de doelsystemen en kan hij daar, met zijn nieuwe wachtwoord, inloggen. 19

20 Afbeelding 10 Gebruiker kan inloggen met zijn nieuwe wachtwoord Ook in het inlogscherm van Identity Manager gebruikt hij vanaf nu zijn nieuwe wachtwoord en niet meer zijn activeringscode. 20

21 Afbeelding 11 Deactiveren van een account Dit is het scherm dat beheerders zien als ze een account willen deactiveren. Er verschijnt een lijstje met alle actieve accounts (voor externen). De beheerder kiest een account en kiest uit het keuzelijstje een reden. In een productiesysteem zou afhankelijk van de reden een periode ingaan gedurende welke de gebruiker nog kan inloggen in alle, of een deel van de doelsystemen (te configureren per reden en per doelsysteem). Voor demonstratiedoeleinden is er voor gekozen om in de PoC deze periode 0 dagen te laten zijn voor alle redenen. Dit wil zeggen dat accounts (onafhankelijk van de reden) per direct gedeactiveerd worden. 21

22 Afbeelding 12 Heractiveren van een account Als een beheerder een gedeactiveerd account weer wil activeren kan dat via dit scherm. In het lijstje zijn alle gedeactiveerde accounts te zien. Door een account te selecteren en op Heractiveer te klikken wordt het account weer actief (met het zelfde wachtwoord als voordat het account gedeactiveerd werd). 22

23 Afbeelding 13 Aanmaken van een gebruiker via een.csv bestand Het aanmaken van een student account kan niet via een menuoptie in Identity Manager maar gebeurt op basis van gegevens die uit het SIS komen. In de PoC wordt het SIS gesimuleerd door een.csv bestand. De driver kijkt om de 10 seconden of een bepaald bestand input.csv bestaat. Als dat zo is wordt het bestand ingelezen en wordt op basis van de gegevens in de.csv file een account aangemaakt. In het screenshot is o.a. de inhoud van een bestand te zien. Het bevat 1 gebruiker Ted van der Test, de getallen zijn geboorte- start- en einddatum (in seconden sinds 1970). De M staat voor Mannelijk en FNW is de opleiding die deze student volgt. Er kunnen nog wat meer velden ingevuld worden (vandaar de komma s aan het eind) maar die zijn voor de PoC niet van belang. 23

24 Afbeelding 14 Een studentaccount een activeringscode geven Een studentbeheerder (IaaSStudentAdmin) heeft 3 mogelijkheden (naast het wijzigen van zijn eigen wachtwoord): Een student een activeringscode geven. Een actieve account deactiveren. Een gedeactiveerd account heractiveren. Dit scherm toont de interface om een activeringscode in te stellen. Dit werkt hetzelfde als voor accounts voor externen. In de lijst staan nu de studentenaccounts die op basis van de.csv file zijn aangemaakt. In een productiesysteem zou het wenselijk zijn voor veel studenten tegelijk een activeringscode te genereren en de complete lijst (bijvoorbeeld als.csv) te exporteren. Deze functionaliteit is in de PoC niet ingebouwd. De interfaces om studenten te deactiveren en heractiveren zien er hetzelfde uit en werken hetzelfde als de schermen om een account voor een externe te deactiveren en heractiveren. Daarom worden ze hier niet getoond en beschreven. 24

25 5. Bevindingen 5.1. Standaard, configureerbaar en maatwerk Bron- en doelsystemen De koppeling met bron- en doelsystemen zal altijd maatwerk blijven. Voor elke instelling zullen de bron- en doelsystemen, maar ook de (naamgeving van de) attributen die de systemen opleveren of nodig hebben, anders zijn. Een koppeling van een bepaald systeem (bijvoorbeeld Iris als studenten informatiesysteem) kan natuurlijk wel lijken op een eerdere koppeling van datzelfde systeem naarmate dit vaker is gedaan. Het koppelen van veel voorkomende systemen zal dus steeds eenvoudiger worden. Per doelsysteem zal ook moeten worden bepaald welke typen accounts er toegang hebben tot het betreffende systeem Redenen voor deactivering In het systeem is een overgangsperiode voorzien. Op die manier worden gebruikers niet per direct afgesloten maar pas na een bepaalde tijd. De redenen voor het deactiveren van een account bepalen welke systemen er tijdens de overgangsperiode nog beschikbaar zijn en welke niet meer en hoe lang de overgangsperiode duurt. Indien de reden bijvoorbeeld Ontslag op staande voet is dan zullen alle systemen onmiddellijk (dus met een overgangsperiode van 0 dagen) worden geblokkeerd. Er zal voor elke instelling een aantal tabellen moeten worden ingevuld (1 voor elk type account) waarbij de kolommen gevormd worden door de gekoppelde doelsystemen en de regels door de verschillende redenen van deactivering van een account. In elk veld van de tabel zal dan moeten worden aangegeven hoe lang de overgangsperiode is. Daarbij betekent 0 dat het betreffende systeem tijdens de overgangsperiode niet beschikbaar is. Ter illustratie hier een deel van een dergelijke tabel voor het accounttype medewerker, met een tweetal doelsystemen en 4 redenen van deactivering van het account. Bij Ontslag op staande voet wordt alles direct afgesloten. Een gepensioneerde mag nog een jaar lang gebruik maken van webmail, maar heeft geen toegang tot het netwerk meer nodig. Is iemand overleden of is het dienstverband beëindigd dan is het nog 30 dagen mogelijk om een back-up van zijn mail te maken. Overgangsperiode per systeem en per reden in dagen, Webmail Netwerktoegang Ontslag op staande voet 0 0 Met pensioen Overleden 30 0 Dienstverband beëindigd 30 0 De lijst met redenen kan per type account anders zijn en is ook deel van de configuratie. 25

26 Beheeraccounts Een ander belangrijk aspect bij het configureren van het systeem is de inrichting van de beheeraccounts. Welke accounts bestaan er met beheerrechten en welke groepen van accounts (medewerkers, studenten etc.) mag elke beheeraccount beheren? Er zal nader moeten worden nagedacht over een manier om dit zo generiek mogelijk te maken en de instellingen die het systeem gebruiken toch genoeg flexibiliteit te bieden Standaard functionaliteit De rest van het systeem zal voor alle instellingen gelijk zijn. Dit betreft dan met name de typen accounts, de statussen die ze kunnen doorlopen en de interface waarin bepaalde acties plaatsvinden. Voor de interface is het wellicht wel mogelijk de look & feel aan te passen aan de wensen van de instelling. Als een instelling wensen op het gebied van typen accounts, statussen van die accounts of de interface heeft dan zal dit altijd in de vorm van een maatwerkproject moeten worden uitgevoerd Bevindingen van de instellingen Christelijke Hogeschool Ede De Christelijk Hogeschool Ede (CHE) gaf in de eerste plaats aan dat veel van de processen die beschreven zijn een verbetering zouden zijn van de huidige situatie. Het zou in een aantal gevallen wel een verandering van werkwijze vereisen maar het lijkt niet tot meer werk te leiden voor een bepaalde afdeling. Er wordt dus weinig weerstand vanuit de organisatie verwacht. Daarnaast zou de invoering van (een systeem als) IaaS leiden tot een verbetering van de beveiliging en auditing. Ook zou de automatische provisioning naar doelsystemen een snelheidswinst betekenen. De CHE gaf aan maar een deel van de accounts te kunnen gebruiken. Met name accounts voor scholieren en vooraanmelders zouden niet gebruikt worden. Dit levert verder geen probleem op bij het gebruik van het systeem, alleen wordt een deel van de geboden functionaliteit niet gebruikt. Dat studenten voor een wachtwoord reset altijd naar een beheerder toe moeten is niet wenselijk, vindt CHE. Dit zou een te grote belasting van de beheerder(s) vergen. In een productiesysteem zal het initiatief ook bij de student moeten kunnen liggen en zonder tussenkomst van een beheerder moeten kunnen plaatsvinden. Hier zijn verschillende mogelijkheden voor te bedenken, zo zou de activeringscode g d kunnen worden (als een extern adres bekend is) of zou de gebruiker een set juiste antwoorden op vragen moeten geven waarna het antwoord getoond wordt. Denk hierbij aan persoonlijke vragen als Wat is de meisjesnaam van je moeder?. Beide opties zijn vrij eenvoudig aan het huidige systeem toe te voegen (de vraag/antwoord optie is ingebouwde functionaliteit van Noveel IdM). Voor medewerkers vindt de CHE de gekozen optie wel voldoende. Beleid is dat een medewerker voor een wachtwoordreset door de beheerder wordt teruggebeld. De gekozen opzet in IaaS ondersteunt die mogelijkheid. 26

27 De huidige werkwijze binnen CHE is dat de P & O afdeling maandelijks een lijst oplevert met accounts die gedeactiveerd moeten worden. De verwijdering zou met IaaS automatisch gaan plaatsvinden gebaseerd op de verwijdering uit het bronsysteem. Dit vergt dus een iets andere werkwijze maar vermindert de hoeveelheid werk bij P & O Radboud Universiteit De Radboud Universiteit gaf aan al eerder tot de conclusie gekomen te zijn dat de identity managementprocessen bij hoger onderwijsinstellingen weinig van elkaar verschillen. Het is in een grote organisatie echter lastig om allerlei keuzes door te drukken, waardoor bij het implementeren van identity management door de eigen organisatie veel consensus nodig is en dus niet altijd de meest efficiënte oplossing gekozen wordt. Dat brengt wel hoge kosten met zich mee. Als gekozen zou worden voor een goedkope oplossing die extern wordt gehost, dan is het misschien mogelijk om iedereen de werkwijzen die bij die oplossing horen te laten accepteren. Ook de Radboud Universiteit gaf aan dat het niet wenselijk was dat de gebruiker zelf geen wachtwoordreset kan uitvoeren. Zij wezen op het feit dat meerdere instellingen op dit moment bezig zijn met een wachtwoordreset via SMS. Deze oplossing zou lastiger toe te voegen zijn dan de eerder genoemde alternatieven. Het systeem zoals dat er nu is houdt geen rekening met dubbele rollen. Dus er is geen apart soort account voor iemand die zowel medewerker als student is. De Radboud Universiteit gaf aan hier moeite mee te hebben voor iemand die én student én alumnus is. De CHE heeft bij navraag aangegeven het juist als wenselijk te ervaren dat personen met dubbele rollen ook verschillende accounts voor die rollen hebben. 27

28 6. Business case De business case voor identity management in het algemeen heeft natuurlijk te maken met de voordelen die het kan bieden: Gebruiksvriendelijkheid. Tijdigheid, correctheid en volledigheid. Kostenbeheersing bij aanmaken accounts, uitdelen licenties, creeren van nieuwe applicaties, etc. Veiligheid. Privacy. Compliance. Stroomlijning van identity managementprocessen. Deze voordelen zijn niet allemaal te kwantificeren en in de praktijk geldt ook dat instellingen die identity management invoeren geen expliciete kosten/batenanalyse maken. Dat betekent dat zo n analyse voor IaaS ook lastig te doen is, omdat er geen voorbeelden van zijn. Wel kunnen de kosten van IaaS vergeleken worden met die van een eigen maatwerk implementatie. Die vergelijking zal hier gemaakt worden. In de onderstaande tabel zijn de verschillende kostencomponenten van een basisimplementatie voor identity management opgenomen en is steeds aangegeven waar IaaS bespaart: Aspect % Besparing 1 Definitiefase IdM project (commitment, ambitie, scope, roadmap) 50% Door de gestandaardiseerde aanpak is deze fase sneller te doorlopen. Er is een besparing van 50% te verwachten. 2 Beleid opstellen voor IdM 50% Door de gestandaardiseerde aanpak is ook deze fase sneller te doorlopen. Er is een besparing van 50% te verwachten. 3 Architectuur en procesbeschrijvingen opstellen 4 Bepalen van de technische infrastructuur 80% Hier is een grote besparing van wel 80% te verwachten, omdat de technische architectuur niet hoeft te worden gemaakt, de procesbeschrijvingen klaar liggen (alleen geparametriseerd hoeven te worden) en dus eigenlijk alleen een informatiearchitectuur hoeft te worden opgesteld voor het bepalen van bron- en doelsystemen en het toebedelen van rechten bij rollen in de doelsystemen. 100% Zaken als bepalen van technische componenten en standaarden en het uitvoeren van een productselectie kunnen achterwege blijven. Hierop is dus een maximale besparing van 100%. 5 Implementatie 5a Koppelingen 20% Eenmalige kosten voor koppelingen met bron- en doelsystemen blijven uiteraard overeind, maar het bouwen ervan is wel iets efficienter dan in een volledig maatwerkproject. 20% besparing. 5b Centrale infrastructuur voor 50% De centrale identity 28

29 identity management managementinfrastructuur is al ingericht door de IaaS-leverancier. Die zal echter de kosten voor het eenmalig inrichten hiervan omslaan naar een prijs per jaar en zal ook enige kosten vragen voor eenmalige inrichting. De besparing is geschat op 50%. 5c Implementatie in de organisatie 30% De kosten voor implementatie in de organisatie (die zal zich moeten aanpassen aan het werken met de IaaS interfaces) liggen ook wat lager. Er zal minder discussie over details (mogelijk) zijn, maar er zijn wellicht meer wijzigingen op werkwijzen dan bij een maatwerk project, waardoor op dit deelaspect geen 100% besparing te halen valt. De geschatte besparing is 30% 5d federatiekoppeling 80% De Federatiekoppeling wordt automatisch door de aanbieder verzorgd, maar er zijn natuurlijk wel enige maatwerkwerkzaamheden op het vlak van communicatie en configuratie. 6 Hardware, systeemsoftware, housing, netwerk, etc. 7 Softwarelicenties voor IdM software 8 Beheer en support door leverancier Systeembeheer Technisch applicatiebeheer Support 9 Functioneel beheer door de instelling 20% Deze kosten liggen bij een gehoste dienst lager, omdat de voorzieningen efficienter gebruikt kunnen worden. Hier is een besparing van 20% te verwachten 0% Mogelijk kan een aanbieder van IaaS licenties goedkoper verkrijgen, maar meestal zijn de onderwijslicenties al behoorlijk scherp geprijsd. Hier is veiligheidshalve uitgegaan van geen besparing. 20% De feitelijke kosten bij een gelijke omgeving zullen hier iets lager liggen bij IaaS door efficiency, maar een leverancier zal altijd een zekere marge vragen waardoor de prijs vaak in de buurt ligt van eigen beheerkosten. Echter, de IaaS-omgeving zal per definitie minder complex zijn dan een maatwerkomgeving en daardoor zullen de beheerkosten toch lager liggen. De geschatte besparing is 20%. 20% Het functioneel beheer zal eenvoudiger zijn omdat de omgeving geen grote complexiteit kent en bijvoorbeeld de gewenste wijzigingen minder groot in aantal zullen zijn. De geschatte besparing komt op 20% 10 Projecten?% Alle identity managementtrajecten kennen meerdere projecten. Nadat een 29

30 basisinfrastructuur is ingericht moeten meer applicaties worden ontsloten of wordt SSO geïmplementeerd, wordt sterke authenticatie ingevoerd, etc. Voor dergelijke projecten is het nog te vroeg om te zeggen of die in een IaaS setting goedkoper zullen zijn. Daar zal een pilot meer inzicht in geven. 30

31 7. Conclusie De eerste conclusie is dat de dienst voor een kleinere instelling bruikbaar is. De typen accounts zijn ruim voldoende (en worden zelfs niet overal allemaal gebruikt). De configureerbaarheid van redenen van deactiveren is ook meer dan kleine instellingen nodig hebben. In de praktijk blijkt er niet zo veel verschil te zitten in de verschillende redenen. Maar de huidige opzet biedt in ieder geval de mogelijkheid om diverse varianten te configureren. Het aan de in IaaS gebruikte processen aanpassen van de werkwijze wordt door de instellingen niet als een groot probleem gezien. Deze veranderingen wegen op tegen de voordelen van IaaS. De nieuwe werkwijze zou ook niet meer tijd kosten dan de huidige werkwijze en zou in sommige gevallen een snellere werkwijze zijn gezien de automatische verwerking van veranderingen in de bronsystemen. Het is opmerkelijk dat als een voordeel van een standaarddienst wordt ervaren dat er voor de instelling geen keuze is in bepaalde mogelijkheden. Dit beperkt de interne discussie over het te kiezen alternatief. De tabel met de kostenbesparing geeft aan dat er behoorlijke besparingen kunnen worden behaald met de IaaS-dienst, maar een vraag die niet onmiddellijk beantwoord kan worden is of de commerciële prijs voor de dienst daarmee aanvaardbaar is voor klanten. IGI Group is momenteel bezig om de kosten voor een IaaS-dienst te bepalen. Verwacht wordt dat op basis daarvan in januari 2010 een prijs kan worden afgegeven voor de dienst. Vervolgens moet blijken of kleinere instellingen bereid zijn die prijs te betalen. 31