Een state of the art FODA feature-diagram toegepast bij de beoordeling van een ID&AM architectuur. Door Bob de Haan. Januari 2012

Een state of the art FODA feature-diagram toegepast bij de beoordeling van een ID&AM architectuur. Door Bob de Haan Januari 2012 Eenjarige Master Software Engineering Afstudeerdocent: Prof. Dr. Paul Klint Stagebegeleider: Arie Spee Opdrachtgever: Raet Publicatiestatus: Openbaar Universiteit van Amsterdam

1

Inhoudsopgave

o o o o o o o o o o o o o

Samenvatting Inleiding Inleiding tot het ID&AM domein Validatiemethodiek Het ID&AM feature-diagram De ID&AM referentiearchitecturen Relatie tussen de ID&AM varianten in het feature-diagram en de referentiearchitecturen Beperkingregels Case studie Conclusie Begrippenlijst Standaard producten Referenties

2

Samenvatting

Toen ik de opdracht kreeg om een architectuur te beoordelen op het gebied van Identity & Access Management (ID&AM) stond ik voor de vraag: hoe dit aan te pakken? Ik had wel kennis op het gebied van ID&AM maar dit was zeker niet voldoende om een weloverwogen oordeel te kunnen geven. Het stond vast dat ik in ieder geval mijn kennis op het gebied van ID&AM moest gaan bijwerken. Literatuuronderzoek en onderzoek naar bestaande oplossingen uit de praktijk zijn dan ook uitgevoerd, nadat ik tot dit inzicht was gekomen. Vanuit de studie Software Engineering was ik bekend met de software architectuur evaluatie methode Architecture Tradeoff Analysis Method (ATAM). Deze methode is alom gerespecteerd en heeft zijn nut bewezen. Maar deze methode zou mij niet helpen bij het vergaren van een brede kennis op het gebied van ID&AM omdat ATAM start vanuit kwaliteitseisen en zo stuurt naar een gerichte oplossing. Wat ik nodig had was een methodiek die mij in staat zou stellen om het volledige domein te bestuderen. Een college software product lines bevatte het gebruik van feature-diagrammen om overeenkomsten en varianten in productstraten te modelleren. Het gebruik van feature-diagrammen wordt oorspronkelijk beschreven in Feature-Oriented Domain Analysis (FODA)[42] als product uit een domein analyse. Zo is het idee gegroeid om, in tegenstelling tot de top down ATAM methode, het gebied van ID&AM in kaart te brengen en te modelleren met een state of the art feature-diagram. Onderzoeksvraag Hoe een gegeven ID&AM oplossingarchitectuur te beoordelen? In het hoofdstuk Conclusie wordt nader ingegaan op de wetenschappelijke relevantie van dit onderzoek. Waaronder de volgende opsomming om de scope van het project aan te geven. Uitkomst van deze studie is: 1) Zo goed als volledig domeinonderzoek van ID&AM, 2) Toetsing van feature-diagram aan de hand van referentiearchitecturen, 3) Voorstel validatiemethodiek, 4) Positionering van validatiemethodiek ten opzichte van ATAM, 5) Uitgebreide validatie van een gegeven ID&AM architectuur volgens de methodiek. Deze studie bevat niet: 1) Een wetenschappelijk bewijs van correctheid voor validatiemethodiek, 2) Empirisch onderzoek naar de verschillende architectuurevaluatiemethoden.

Dankwoord Hierbij wil ik mijn waardering uitspreken voor beide begeleiders: Paul Klint en Arie Spee, voor de feedback die ik van hen heb mogen ontvangen.

3

Inleiding

De case die voor deze studie als voorbeeld dient, beschrijft een grote aanpassing van een webarchitectuur op het gebied van ID&AM (Identity & Access Management). Probleemstelling Decentraal beheer van digitale identiteiten binnen een monolithische webarchitectuur is vaak omslachtig, complex en foutgevoelig door impliciet binnen het systeem aanwezig redundante gegevens of afwijkende datastructuren. De reden is, dat voor elke geïntegreerde module zelfstandig en mogelijk onderling afwijkende authenticatie en autorisatie mechanismen worden onderhouden. Waarbij authenticatie methoden kunnen variëren van herhaalde login op basis van naam en wachtwoord tot eenmalige authenticatie met een certificaat of persoonlijke eigenschappen. En het uitdelen van autorisatierechten op basis van een persoonlijk nummer, lidmaatschap van een groep of een bepaalde rol. Authenticatie en autorisatie ID&AM wordt ook wel als aangeduid met de termen Authenticatie en Autorisatie. Authenticatie heeft tot doel vast te stellen dat een persoon of proces is wie het beweert te zijn. Autorisatie heeft tot doel vast te stellen of een vastgestelde identiteit recht heeft op bepaalde systeembronnen (data) en of bepaalde systeemfuncties (programma‟s en processen). Aanpak Om de opdracht „het valideren van een gegeven architectuuroplossing‟ uit te kunnen voeren is een uitvoerig literatuur onderzoek gestart in het ID&AM domein. Referentiearchitecturen van bekende authenticatie- en autorisatie methodieken zijn onderzocht en beschreven. De ontwikkelde domeinkennis is in kaart gebracht door het te modelleren in een ID&AM featurediagram. Dit state of the art feature-diagram ondersteunt het validatie proces omdat alle mogelijke oplossingen op het gebied van ID&AM in het feature-diagram terug te vinden zijn. Het feature-diagram dient als referentiemodel tijdens de beoordeling van een ID&AM oplossingsarchitectuur. Met het feature-diagram is domeinkennis expliciet gemaakt. Bij architectuur evaluatiemethoden als ATAM[22], SAAM[31] of ARID wordt verondersteld dat deze kennis impliciet aanwezig is in de vorm van een architect of evaluatieteam of in een later stadium onderzocht zoals bij ATAM stap 6: Analyze Architectural Approaches. ATAM start bij business drivers, stelt scenario‟s op van een drietal types: gebruik, groei en uitbreiding scenario‟s en komt dan tot een utility tree waarbij bepaalde kwaliteitseigenschappen scenario‟s een plek hebben gekregen voor verdere evaluatie. De hieruit voortvloeiende aandachtspunten risks, sensitivity- and tradeoff- points worden in ATAM verder onderzocht en gemodelleerd voor een beter begrip van de materie. Hier begint bij ATAM een verkenning van het oplossingsdomein[22]. Wat bekend staat als een top down methode. Een geschikte validatiemethodiek is het modelleren van het oplossingsdomein met behulp van een feature-diagram. De uiteindelijke ontwerparchitectuur voor een nieuw ID&AM zal minstens één pad in het overeenkomstige model uit het oplossingsdomein moeten bevatten. Dit is de premisse voor een verdere evaluatie.

4

Inleiding tot het ID&AM domein.

ID&AM maakt een sterke ontwikkeling door. Hoewel de term ID&AM pas enkele jaren in gebruik is bestaat het in principe al sinds het eerste gebruik van computers. [44, 2007] plaatst ID&AM in dit perspectief: “De term Identity and Access Management is bekend voor ongeveer vijf jaar, maar het onderliggende concept is zo oud als de computer zelf. Sinds de uitvinding van computers is er een behoefte om specifieke rechten toe te kennen voor het gebruik van computerbronnen en gegevens. Voorheen werd dit bereikt door toegang tot de computer fysiek te beperken door het te plaatsen in een afgesloten ruimte. De noodzaak om op een efficiënte wijze gebruikers identiteiten te beheren en toegang te verlenen is de laatste tijd snel toegenomen door de opkomst van Internettoepassingen die toegang verlenen tot een rijk geschakeerde set van applicaties en data. Toen ID&AM in zwang raakte werd Single SignOn het belangrijkste component. Met Single Sign-On is het voor gebruikers mogelijk om met een enkel id en wachtwoord toegang te krijgen tot alle applicaties. Hierna startte organisaties met de integratie van gebruikers provisioning. Het idee was eenvoudig. Automatiseer het proces van aanmaken en onderhouden van gebruikeraccounts. Het implementeren van Single Sign-On en gebruikers provisioning bleek voor veel organisaties een complexe aangelegenheid...” En “De komst van identiteit federaties stellen organisaties in staat om ID&AM over hun eigen grenzen heen te tillen.” Positionering van dit verslag ten opzichte van vakliteratuur. De in dit verslag gekozen termen Identiteit, Authenticatie en Autorisatie worden soms in de literatuur anders geformuleerd of gehanteerd. Initiatieven tot standaardisatie en oplossingen op het gebied van ID&AM zijn bijvoorbeeld Microsoft Geneva[14, 15, 16], .MyServices en het Liberty Alliance Project[40]. De Liberty Alliance Architectuur beschrijft drie basis onderdelen: 1) Principal, 2) Identity provider, 3) Service provider. Dit is een fysieke kijk op ID&AM. De genoemde onderdelen zijn in dit verslag te lezen als: 1) Identiteit, 2) Authenticatie, 3) Autorisatie. Waarbij de volgende vertaling gehanteerd wordt: 1) Een principal is een systeemobject die een identiteit vertegenwoordigt, 2) Een identity provider voorziet in het authenticatie proces, 3) Een service provider levert bepaalde functionaliteit aan geautoriseerde identiteiten. Ad. Identity Provider volgens [43]: “Een Identiteiten Provider beheert gebruikers authenticatie en gebruikers identiteitrelevante informatie”. Service Provider volgens [43]: “Een Service Provider levert diensten aan gebruikers die voldoen aan policy requirements verbonden aan deze diensten”. Het gebruik van bedrijfsregels (policy requirements) vindt men vooral terug bij federatieve systemen.

5

Het betreft dezelfde principes die vanuit een ander gezichtspunt benaderd worden. Enkele praktijk voorbeelden. Om een indruk te geven van wat ID&AM inhoudt en welke plek ID&AM in de praktijk inneemt volgt hierna een drietal voorbeelden. Met de voorbeelden wordt de problematiek rond ID&AM beschreven. Terugkerende thematieken zijn: Single Sign-On, Provisioning en Beveiliging. Voorbeeld 1, China Mobile Group [45] geeft aan hoe de problematiek rond ID&AM het bedrijf een verdere groei in de weg gaat staan. Voorbeeld 2, Het International Space Station [46] toont de integratie van een groot pluriform systeem. Voorbeeld 3, Stichting Talant [47] geeft aan dat provisioning vanuit een centraal HR-bronsysteem naar andere modules door inzet van standaard software mogelijk is. 1. China Mobile Group levert o.a. diensten op het gebied van mobiletelefonie. Door de snelle uitbreiding van het aantal klanten, personeel en systemen ontstond een beheerprobleem van gebruikersidentiteiten. Elke gebruiker had voor elk systeem verschillende login accounts. Met een escalerend aantal login accounts als gevolg. Deze uitdijing van sign-on accounts werd voor China Mobile Group een belemmering voor verdere groei. Om dit probleem op te lossen koos China Mobile Groep voor ingebruikname van een uniform user management systeem: Oracle Identity and Access Management Suite. Als voornaamste voordelen wordt genoemd: 1) Versterken van beveiliging, 2) Verbetering van usability, 3) Een efficiënter user- en system management. 2. Het International Space Station (ISS) van NASA is een groot en wijdverspreid wetenschappelijk project. De afdeling NASA Johnson Space Centre levert i.o. van ISS computerdiensten voor een wereldwijde gemeenschap van meer dan 5000 wetenschappers, ingenieurs, managers en andere gebruikers. Omdat de gemeenschap van gebruikers globaal verspreid is, zijn alle relevante applicaties gehost en toegankelijk via een webarchitectuur. De applicaties hebben een eigen geschiedenis en zijn onafhankelijk van elkaar ontstaan. Een variëteit aan technieken en platformen zijn door verschillende teams gebruikt om de applicaties te bouwen en te onderhouden. Het gevolg is een ongecontroleerd gebruik van middelen op een veelvuldig sign-on omgeving zonder een duidelijke authenticatie en autorisatie. De volgende requirements zijn gedefinieerd om genoemd probleem op te lossen. 1) Een gecentraliseerde authenticatie en toegangscontrole voor alle webapplicaties. 2) Voorzie in een single sign-on voor alle ISS middelen. 3) Monitor authenticatie processen en toegangscontrole op een centrale plek. 4) Dwing een sterk wachtwoord beleid af. 5) Laat gebruikers geregeld hun wachtwoord vernieuwen. 6) Notificatie aan de gebruikers over het aflopen van geldigheid van gebruikt wachtwoord. 7) Geeft gebruikers de mogelijkheid om d.m.v. zelfbediening hun wachtwoord te onderhouden. Een complicerende factor voor deze case is het gebruik van meerdere directories. ISS beheerde redundante Sun ONE LDAP servers voor de eigen interne gemeenschap. Met een top-level Active Directory en een afgeleide Active Directory. Gebruikers in deze directories vertegenwoordigde de meeste externe gebruikers met toegang tot de webapplicaties. Een oplossing vond ISS door het inzetten van de tool Cams van het bedrijf cafésoft. Het voorziet in een single sign-on, gecentraliseerd beheer van web toegangsregels, waakt over de naleving van beveiligingsbeleid en controleert de authenticatie- en toegangprocessen. Een redundante cluster van twee beleidsrevers werden ingezet op toegewezen servers. Deze servers hosten toegewezen authenticatie proxy servers. Cams web agent software zijn geïntegreerd binnen de ISS web en applicatieserves, welke ingezet werden achter redundante load balancers. Belangrijkste hoogtepunten: 1) Authenticatie. Login modules zijn zonder problemen aangepast op de niet-standaard Active Directory schama‟s en ingezet ter ondersteuning van de Active Directory nodes en de Sun ONE Directory Server. Een gebruiker is geauthenticeerd als deze wordt gevonden in een van de directories. Groepinformatie wordt geaggregeerd en dan toegewezen aan rollen voor directories ten behoeven van het authenticatie proces. Na een valide authenticatie kan de gebruiker toegang verleend worden tot de geautoriseerde middelen. 2) Oracle Forms Adapter is een client/server applicatie die

6

draait binnen de Oracle Aplication Server. ISS had meer dan 700 Oracle Forms pagina‟s die geïntegreerd zijn in de Cams single sign-on oplossing. Hiervoor is een maatwerk adapter gebouwd die op een transparante wijze sessie informatie doorgeeft aan de Forms voor geautomatiseerde gebruikers authenticatie. 3) Session Event Handlers. Hiermee is het mogelijk geworden voor web applicaties informatie over een gebruiker op te vragen en zonodig hierop te reageren. 4) Identity voor LDAP geeft ISS methoden als account zelfregistratie, wachtwoord reset, onderhoud en beheer van accounts en groepen. Een aangepaste versie voor usermanagement met de Sun ONE Directory Server. Conclusie. ISS is instaat gebleken om de onsamenhangende authenticatie en autorisatie mechanismen te migreren naar een webbased single sign-on systeem met één centraal usermanagement in de vorm van LDAP. 3. Stichting Talant in Friesland. Usermanagement werd oorspronkelijk handmatig uitgevoerd. Gebruikers account werden handmatig aangemaakt, aangepast of verwijderd. Deze handmatige processen zijn foutgevoelig. Bovendien bleven accounts die hoorde bij werknemers die al uit dienst waren te lang in het systeem bestaan. Om de situatie te verbeteren werden de volgende doelstellingen gedefinieerd; 1) Een correct beheer van de user lifecycle om te garanderen dat medewerkers die al uit diens zijn ook werkelijk geen toegang meer hebben tot bepaalde informatie (gegevens autorisatie) en geen toegang meer hebben tot systemen op het netwerk (functionele autorisatie). 2) Vervanging van het handmatige beheer door een geautomatiseerde versie om fouten te voorkomen en een snellere doorvoer van gegevenswisseling. Om deze doelstellingen te halen werd gezocht naar een oplossing die ook aan de volgende eisen moest voldoen. 1) Een kort en snel implementatie traject van hooguit twee maanden. 2) De oplossing moest verder flexibel genoeg zijn om eventueel volgende fusies en reorganisaties te doorstaan. 3) En een interface bieden met bestaande bronsystemen als: Beaufort om gebruikersbeheer taken te kunnen automatiseren. User Management Resource Administrator (UMRA) is de tool de geschikt is gebleken. “Als in 1 van onze HR systemen iets wijzigt met betrekking tot een medewerker past UMRA automatisch alle rechten aan binnen de termijn die de organisatie daar voor stelt”. Volgens hoofd ICT van Talant. UMRA is een gebruikersbeheer oplossing en bevat; delegatie, automatische gebruikers account provisioning, verwijder en migratie onderdelen. Delegatie van gebruikers accounts houdt in dat met een tool een set van scripts gegenereerd worden die vervolgens automatisch uitgevoerd worden bij het aanmaken of verwijderen van een account. Deze set wordt als een template beschikbaar gemaakt aan de beheerder die met enkel de opgave van wat gebruikergegevens accounts beheert. Provisioning integreert gebruikersbeheer taken met de bestaande (HR)bronsystemen als Beaufort. Account informatie wordt gesynchroniseerd gedeeld over de HR systemen en account informatie in het netwerk. Hierdoor wordt het handmatige werk of delegatie versimpeld en geautomatiseerd. Het HR systeem wordt gezien als informatie bronsysteem en is leidend. Accounts worden geïntegreerd met de HR systemen en het netwerk. Veranderingen in een van de HR systemen kunnen automatisch gepropageerd worden naar bijvoorbeeld een Active Directory en Visa Versa. Connectoren zorgen voor de integratie. Zij kunnen verbinden met: 1) Beaufort, SAP HR, PeopleSoft, ADP en vele andere partijen met Microsoft Active Directory, Novelle Directory, Novell GroupWise, Lotus Notes Domino, Linux OpenLDAP, Sun ServerOne of andere LDAP gebaseerde directory systemen. Standaard oplossingen. Het hoofdstuk Standaard producten geeft voor een aantal softwareleveranciers standaard oplossingen. Het gebruik van standaard oplossingen is afhankelijk van de flexibiliteit van de architectuur die gebruik moet gaan maken van een standaardoplossing en de features en zwaartepunt van de features van een standaardoplossing.

7

Validatiemethodiek.

Om de opdracht beoordeel een gegeven ID&AM architectuur handen en voeten te geven en op een gestructureerde wijze uit te voeren is volgende validatiemethodiek opgeschreven en toegepast. Een feature-diagram structureert de samenhang van alle mogelijke elementen binnen een onderwerp. Met feature-diagrammen worden overeenkomsten en mogelijke variaties per aspect gemodelleerd[23] uit het ID&AM oplossingsdomein[42]. Dit model is het product van de literatuurstudie waarmee een poging is gedaan om ID&AM in kaart te brengen. Het doel van deze inspanning is om de validatie van een gegeven oplossing, zoals beschreven is in de case, te onderbouwen aan de hand van genoemd model. Een gekozen oplossing zal dan een pad in het feature-diagram moeten zijn. Als het pad niet aanwezig is, kan het zijn dat: 1) De oplossing niet bekend is of 2) De gegeven oplossing niet valide is. In beide gevallen zal dit nader beschouwd moeten worden. Het feature-diagram uit het oplossingsdomein kan in het eerste geval aangepast worden aan de nieuwe inzichten met de nieuwe features van een oplossing uit het probleemdomein. Als het pad wel voorkomt voor één aspect kan gesteld worden dat de oplossing een bekende en aanvaarde oplossing is omdat het feature-diagram alle mogelijke oplossingen beschrijft. Het doel voor toepassing van voorgestelde validatiemethodiek is om op een gestructureerde wijze de oplossing te valideren aan de hand van een geaccepteerd model. Hierbij biedt het model houvast tijdens de evaluatie en kan richting geven aan het evaluatieproces.

Flowchart validatiemethodiek.

8

De methodiek is opgebouwd uit twee fasen: 1) Fase 1. Het beslissingselement in flowchart.”Oplossing heeft pad in feature-diagram”, 2) Fase 2. Het proces element in de flowchart. “Kwaliteitanalyse”. Ad. Fase 1 is het vinden van een pad in het feature-diagram. Fase 2 gaat pas in als aan de voorwaarde in fase 1 is voldaan: Oplossing heeft pad in feature-diagram. In deze volgende fase wordt er vanuit gegaan dat de gegeven oplossing een bekende oplossing is. De features van de gegeven oplossing kunnen voorzien worden van een weging en cardinaliteit. De cardinaliteit geeft aan hoeveel elementen van deze feature aanwezig kunnen zijn. De weging is afhankelijk van gestelde doelen en gegeven requirements. Zo wordt het belang van een feature vastgelegd wat weer van invloed is op het evaluatieproces. Dit proces krijgt een kader door de opbouw van het feature-diagram. Elke feature kan tijdens de validatie aan bod komen. Waar rekening gehouden wordt met de mogelijk onderlinge afhankelijkheden tussen de features. Voorbeeld Single Sign-On Met het Login feature wordt Single Sign-On gemodelleerd door de feature te voorzien van het getal 1. De eigenschap B staat voor belangrijk en de feature zal daarom tijdens een evaluatie zwaar meewegen.

Single Sign-On model met Login feature.

9

Het ID&AM feature-diagram.

De editor waarmee de feature-diagrammen zijn gemaakt is een plug-in voor Eclipse. Een strikt gebruik van feature-notatie[42, 23, 24] wordt door deze editor afgedwongen. Elk diagram wordt voorzien van een legenda met notaties. Feature definitie: “Een feature-diagram ook wel een Feature-Oriented Domain Analysis (FODA) genaamd[42] is een boom of gerichte acyclische graaf waarmee geldige combinaties van elementen gemodelleerd kunnen worden”. Alle bekende oplossingen zijn in het ID&AM feature-diagram gevat. Het geeft een afspiegeling van het ID&AM oplossingsdomein. De mogelijke varianten zoals die in het hoofdstuk referentie architecturen worden beschreven, zijn te herleiden doordat elementen of combinaties van elementen optioneel of verplicht kunnen zijn. De elementen kunnen ook een cardinaliteit bezitten waarmee aangegeven wordt of het betreffende component 0, 1 of meerdere malen voor kan komen. Het gebruik van cardinaliteit binnen feature-diagrammen wordt in[23, 24] voorgesteld als een nuttige toevoeging op de bestaande notatie. De plug-in voor Eclipse heeft deze optie niet. Waar nodig is cardinaliteit handmatig toegevoegd. Het feature-diagram is een belangrijk instrument bij de evaluatie van een mogelijke oplossing omdat het in principe de oplossing bevat. Het geeft verder structuur aan het evaluatieproces omdat de elementen van een gegeven architectuur stap voor stap vergeleken kunnen worden met het feature-diagram. Volgens voorgestelde evaluatiemethodiek zal de oplossing een mogelijk pad in het feature-diagram zijn. Zie voor een voorbeeld uitwerking de evaluatie van een oplossing in de beschreven case. De vraag of het feature-diagram inderdaad state of the art is wordt beantwoordt in het hoofdstuk Relatie tussen de ID&AM varianten in het feature-diagram en de referentiearchitecturen. De meest gangbare architecturen worden dan vergeleken met featurediagram. Alle elementen in het diagram worden verklaard in de begrippenlijst. Bladzijde 39. Het ID&AM feature-diagram

10

Feature notatie Het feature-diagram is opgebouwd uit minstens een feature. De features zijn hiërarchisch gestructureerd. Elke feature kan een of meerdere uitgaande vertakkingen naar andere features hebben. Met een feature per uitgaande vertakking en een ingaande tak. De root of basis feature, de bovenste feature heeft geen ingaande tak en de onderste features hebben geen uitgaande vertakking. De notatie voor verbinding tussen de features is als volgt: 1) Verplicht (Mandatory) Een uitgaande tak met een gesloten cirkel. Deze feature is verplicht, 2) Optioneel (Optional) Een uitgaande tak met een open cirkel. Deze feature kan gekozen worden maar is niet verplicht, 3) OF (Or) Twee of meerdere uitgaande takken met een gesloten halve cirkel in de oorsprong. Niet alle features zijn verplicht. Maar er wordt minstens een verwacht, 4) Alternatief (Alternative) Twee of meerdere uitgaande takken met een open halve cirkel in de oorsprong. Niet alle features zijn verplicht. Zij zijn allen optioneel, 5) EN (And) Twee of meerdere uitgaande takken zonder cirkel. Alle features zijn verplicht. Voor bovenliggende feature. Legenda:

Omwille van de leesbaarheid wordt het feature-diagram getoond vanaf de knopen in de eerste laag: 1) Authenticatie, 2) Autorisatie, 3) Gegevens.

11

Authenticatie

Zie begrippenlijst voor een omschrijving van de in het diagram gebruikte features. Bladzijde 39.

12

Autorisatie

Zie begrippenlijst voor een omschrijving van de in het diagram gebruikte features. Bladzijde 39.

Gegevens

Zie begrippenlijst voor een omschrijving van de in het diagram gebruikte features. Bladzijde 39.

13

De ID&AM referentiearchitecturen.

De bestudering van het ID&AM domein heeft een aantal referentiearchitecturen opgeleverd die in dit hoofdstuk worden beschreven. ID&AM wordt opgedeeld in: 1) Een minimale configuratie voor ID&AM, 2) De scope van een systeem, 3) Centraal of decentraal ID&AM.

1. Minimale configuratie Algemeen Het doel van ID&AM is het verlenen van (gedeelde) toegang tot informatiesystemen aan de daartoe geautoriseerde personen of systemen. De twee onderdelen van ID&AM Het beheren van identiteiten, personen of systemen (Identity Management) is een van de twee onderdelen van ID&AM en ondersteunt het authenticatie proces. Het tweede onderdeel (Access Management) richt zich op toekennen en controleren van autorisaties, het autorisatieproces. Beheer van identiteiten (Identity Management) wordt in de literatuur vaak aangeduid als het provisioning proces of Identity Lifecycle Management. IDM Volgens[34] zijn architecturen voor IDM binnen één organisatorische begrenzing goed beheersbaar en is in de literatuur veelvuldig beschreven. Het bevat minstens één centrale identiteiten server met een relationele database of Active Directory. Gebruikers kunnen soms hun eigen persoonsgegevens beheren en systeemadministratoren beheren de toegangsrechten van deze gebruikers. Vaak zijn de processen voor gegevensuitwisseling geautomatiseerd. Wat is dan de minimale configuratie? Een publicatie op het gebied van Identity and Access Management uit 2003 van Gartner[9] geeft de volgende definitie voor ID&AM: “Bedrijven moeten ervoor zorgen dat gebruikers van IT bronnen geïdentificeerd en voldoende gevalideerd zijn - dit is authenticatie. Zij moeten weten dat hun gebruikers alleen toegang hebben tot de systeembronnen waar zij recht ophebben en die hun functie toestaat - dit is autorisatie. Deze bedrijven hebben een domeinbreed beheer nodig van toegangscontrole - dit is de administratie. Verder moeten zij erop toezien dat alle activiteiten die betrekking hebben tot toegangscontrole bijgehouden worden - dit is controleren.” Gartner is een onderzoekbureau dat adviseert en publiceert op IT gebied. De minimale systeemconfiguratie voor een enkel domein IDM systeem is volgens dezelfde publicatie: 1) Wachtwoord beheer,

14

2) Gebruikers provisioning, 3) Metadirectories voor vastleggen gebruikersinformatie. Ad. Punt 1 is gedateerd en wordt tegenwoordig vervangen door single sign-on mechanismen en het toepassen van (federatieve) identity servers voor authenticatie. Punt 3 door Active Directory, Active Directory voor meerdere domeinen en relationele databases. ID&AM Autorisatie, het tweede deel van ID&AM, wordt beschreven als het gecontroleerd autoriseren op systeemfuncties en systeembronnen voor een geauthenticeerde identiteit. Dit is een vast onderdeel binnen ID&AM en wordt in de volgende opsomming onder punt 1 benoemd. ID&AM bevat standaard de volgende onderdelen: 1) Beheren van toegangsrechten[3, 4, 7, 9, 15, 38] voor het gecontroleerd verstrekken van rechten op systeembronnen, 2) Gebruikers provisioning[4, 7, 8, 9, 10, 15, 34, 38] om identiteiten aan te maken, aan te passen en weer te verwijderen uit het systeem, 3) Een centrale identiteiten server met een relationele database of een Active Directory om identiteiten en accounts in op te slaan[1, 2, 7, 34, 38]. Hiermee is de minimale configuratie voor ID&AM beschreven. De elementen voor deze minimale configuratie zijn terug te vinden in het standaard feature-diagram in de eerste laag vanuit de top gezien. Zie het hoofdstuk feature-diagram. 2. Indeling naar scope ID&AM systemen worden volgens [4] gekarakteriseerd op basis van scope. [39] voegt hier het eerste element “geïsoleerd” aan toe. De vier indelingen zijn: 1) 2) 3) 4)

Geïsoleerd[39], Enkel domein[4, 39], Beperkt aantal domeinen[4], Federatie[4, 39].

Een mogelijke indeling op basis van een al dan niet verdeeld identiteiten beheer is: 1) Centraal, 2) Decentraal. Geïsoleerd. Een systeem waarbij account of wachtwoordmanagement en identiteitsverificatie binnen een service/applicatie geregeld is. Identificatiegegevens worden hierbij niet uitgewisseld met andere systemen. Enkel domein. Een centraal IDM systeem voor een of meerdere services/applicaties met ieder een eigen autorisatie mechanisme binnen het domein. Beperkt aantal domeinen Een systeem van aaneengesloten organisaties (domeinen) met een enkele identity server. Federatief Federaties van aaneengesloten ID&AM systemen accepteren valide identiteiten op basis van onderling vertrouwen. Als een identiteit succesvol geïdentificeerd is door een van de aangesloten identiteitsservers kan deze identiteit geaccepteerd worden door de andere aangesloten systemen op basis van mogelijk per systeem verschillende beleidsregels, policy control. Hierna kan de claim van een bepaalde identiteit verder geautoriseerd worden.

15

Een federatie is een groep van aaneengesloten organisaties of service providers[41] op basis van onderling vertrouwen, trust. Zij zijn in staat om identiteitsinformatie onderling te delen. Hybride omgevingen. Er zijn ook architecturen denkbaar en beschreven waar de beschreven indeling niet altijd even strikt te hanteren is zoals bij volgend voorbeeld van een architectuur met verschillende autorisatieschama‟s waarin ID&AM in het perspectief wordt geplaatst van een cross-domain architectuur[35] en twee systemen ieder een eigen autorisatie mechanisme (schema) hanteren: 1) Inzet van XML technologieën als SAML en XACML, 2) Het gebruik van X.509 certificaten. Autorisatie wordt geïntegreerd op basis van rollen en op basis van X.509 certificaten waarbij rollen aan gebruikers worden toegekend door de certificaten. 3. Centraal en Decentraal. Bij een centraal ID&AM systeem worden identiteiten op een punt beheerd. Enkel domein is hier een voorbeeld van. Bij decentrale architecturen is het beheerd verspreid over meer dan een service. Federatieve- maar ook geïsoleerde systemen zijn hier een voorbeeld van waarbij federatieve systemen identiteitsinformatie onderling uitwisselen en een geïsoleerd systeem niet.

16

Relatie tussen de ID&AM varianten in het featurediagram en de referentiearchitecturen.

Door het feature-diagram met de bekende referentiearchitecturen te vergelijken wordt aangetoond dat het gegeven feature-diagram inderdaad state of the art is voor de gegeven referentiearchitecturen. Hiervoor wordt de volgende vraag gesteld: ”Zijn de referentiearchitecturen herkenbaar in het feature-diagram?” Mogelijke indelingen voor ID&AM zijn: 1) De scope van het systeem, 2) Een centrale of decentrale dataopslag, 3) Complexiteit van een systeem, 4) Of de noodzaak tot beveiliging. Ad. De indelingen 1 en 2 zijn aan de orde gekomen in De ID&AM referentiearchitecturen. Complexiteit en beveiliging geven een andere kijk op 1 en 2 maar voegen verder geen nieuwe features aan het feature-diagram toe. Geïsoleerd Een geïsoleerd systeem bevat accountbeheer en identiteitsverificatie, vaak in de vorm van gebruikersnaam en wachtwoord. Er worden geen gegevens buiten het systeem gedeeld met andere systemen. Vandaar de term geïsoleerd. De elementen voor authenticatie en autorisatie zijn: 1) 2) 3) 4)

Verificatiemechanisme, Accountbeheer met of zonder provisioning, Valideren, Toekennen.

17

Afgeleid feature-diagram voor een geïsoleerd systeem uit het ID&AM feature-diagram. Bladzijde 10. Door het reduceren van alternatieven tot één verplicht feature Geïsoleerd onder de feature Bereik uit de tak Authenticatie vervallen de mogelijke features Aggregatie, Netwerk, Verdeeld, AD, LDAP, Indirect, Systeem, Machine, Uitwisseling en hun onderliggende features van het ID&AM feature-diagram. Het IDM feature-diagram Geïsoleerd is een subset van het originele IDM Authenticatie. Ter verduidelijking een afbeelding van de features op het origineel.

Afbeelding van het IDM Feature-diagram voor een geïsoleerd systeem op het volledige IDM domein. Bladzijde 12. Het diagram van een geïsoleerd systeem bevat ondanks het gesloten karakter veel elementen omdat de authenticatie- en autorisatiemechanismen ondersteund moeten worden. Het provisioning proces kan eenvoudig geïmplementeerd worden omdat er geen data-aggregatie en synchronisatie plaatsvindt over meerdere domeinen heen. Verificatie is direct en vaak op basis van een gebruikersnaam en wachtwoord. Voor het autorisatiemechanisme wordt een persoon gevalideerd op basis van een in het systeem aanwezig principal- of beveiligd object. Deze wordt toegang verleend op functionaliteit of bron. Gegevens zijn alleen beschikbaar via aan het proces toegekend geheugen. Kenmerkend probleem van een geïsoleerd systeem is dat personen die gebruik maken van een dergelijk systeem voor elke applicatie/service een gebruikersnaam en wachtwoord moeten onthouden. Soms wordt dit opgelost door het gebruik van identificatie hardware als de SmartCard. Zie de directe verificatie van een machine in het volgend feature-diagram.

18

Afgeleid feature-diagram voor een geïsoleerd systeem met Smartcard verificatie uit het ID&AM feature-diagram. Bladzijde 10. Enkel domein Een enkel domein systeem verschilt ten opzichte van een geïsoleerd systeem op het gebied van scope. Bij een geïsoleerd systeem bestaan de elementen voor authenticatie en autorisatie binnen een gesloten systeem. De elementen voor authenticatie en autorisatie in een enkel domein kunnen op zichzelf staande systemen zijn binnen het domein. Waarbij de definitie voor een domein kan zijn: Een beveiligd domein zoals een intranet met firewall of een organisatorische eenheid. Een enkel domein systeem kan dus uit meerdere systemen opgebouwd zijn. Met een eigen IDM systeem voor identiteitenbeheer en verificatie.

Afgeleid feature-diagram voor een enkel domein systeem uit het IDM feature-diagram. Bladzijde 10.

19

Dit diagram is beperkt tot IDM omwille van de leesbaarheid. De autorisatiemogelijkheden zijn overigens gelijk aan het geïsoleerde systeem.

Afbeelding van het IDM Feature-diagram voor een enkel domein systeem op het volledige IDM domein. Bladzijde 12. Beperkt aantal domeinen

20

Afgeleid feature-diagram voor een beperkt aantal domeinen systeem uit het ID&AM featurediagram. Bladzijde 10. Voor IDM is er geen verschil tussen een enkel domein en een beperkt aantal domeinen omdat in beide gevallen gebruik gemaakt wordt van een enkele identiteiten server. Voor een beperkt aantal domeinen met een enkele IDM wordt het netwerk beveiligingsaspect wel belangrijk omdat gegevens over een netwerk gedeeld gaan worden.

Afbeelding van Gegevens voor een beveiligd netwerk systeem. Een beveiligd netwerk bestaat uit de volgende features: 1) Beveiligd. Een beveiligde gegevensuitwisseling over een netwerk is mogelijk door inzet van encryptie, 2) Integer. Data-integriteit betekend dat gegevens worden ontvangen zoals de verzender deze heeft verzonden, 3) Vertrouwd. Gegevens kunnen alleen gebruikt worden door de persoon of systemen waarvoor deze gegevens bedoeld zijn. [5] zegt hierover: ”Data moet worden beschermd tegen ongeautoriseerde toegang. Dit wordt in de meeste gevallen bereikt door encryptie van de gegevens en communicatie verbindingen. Encryptie geeft een extra bescherming voor persistente data waar ook autorisatie toegepast wordt. Communicatie verbindingen, echter, beschikken niet over autorisatie middelen. Encryptie is hierbij de enige bescherming tijdens het versturen van vertrouwelijke informatie over publieke communicatie kanalen.” Voor Internet applicaties is in dit geval communicatie over een https verbinding, over een Secure Socket Layer, aan te bevelen. Virtual Private Network (VPN) is een ander voorbeeld van een methode om een beveiligde verbinding tot stand te brengen.

21

Federatie

Afgeleid feature-diagram voor een beperkt federatief systeem uit het ID&AM feature-diagram. Bladzijde 10. Hoewel een federatieve architectuur de meeste complexiteit kan bevatten is er een heel eenvoudige architectuur denkbaar. Zie bovenstaand model. Dit model maakt gebruik van een indirecte authenticatie zonder IDM waarbij de verificatie gedelegeerd wordt naar een vertouwde partij. Dit voorbeeld geeft aan dat scope en complexiteit niet noodzakelijkerwijs samengaan. Volgend voorbeeld van een federatief systeem is echter gangbaarder.

22

Afgeleid feature-diagram voor een volledig federatief systeem uit het ID&AM feature-diagram. Bladzijde 10. Door het wegreduceren van de feature Geïsoleerd onder de feature Bereik uit de tak Authenticatie zijn nagenoeg alle features uit het IDM feature-diagram actief aanwezig. Het betreft een diagram voor een federatief systeem met de volgende eigenschappen: 1) Een feature Domein met cardinaliteit n, 2) Een feature Verdeeld onder de feature Domein waar gestandaardiseerde technieken als ADFS, SAML en SPML een rol gaan spelen, 3) Een feature Verificatie met cardinaliteit n. Met onderliggende features Direct of Indirect, 4) Een feature Trust onder de feature Indirect, 5) Een feature Netwerkprotocol en Kerberos onder de feature Indirect, 6) Een feature Beheer met cardinaliteit n. Ieder met een eigen feature Provisioning en Onderhoud. Ter ondersteuning van identiteitenbeheer, het provisioning proces, gegevensuitwisseling tussen de aangesloten domeinen binnen een federatie, indirecte verificatie en toegangcontrole zijn de volgende standaarden ontwikkeld: 1) SAML is een op XML gebaseerde voorziening voor het beveiligd uitwisselen van identiteit gegevens over verschillende domeinen heen. Het abstraheert onderliggende infrastructuren als Kerberos, PKI en LDAP, 2) SPML is een op XML gebaseerde standaard ter ondersteuning van het provisioning proces tussen verschillende systemen op verschillende domeinen. Hiermee kunnen ook onderling verschillende datastructuren op elkaar afgebeeld worden om zo attributen tussen de verschillende systemen te delen, 3) XACML is een op XML gebaseerde taalstandaard voor de beschrijving van beleidsregels. Het beschrijft regels voor toegangcontrole en definieert methoden, datatypen en logica, 4) ADFS integreert het gebruik van digitale identiteiten tussen verschillende organisaties. Waarbij elke organisatie alleen die identiteiten beheert waar zij eigenaar van zijn. ADFS komt voort uit Active Directory (AD), dat ten doel heeft om persoonsgegevens centraal op te slaan en weer toegankelijk te maken. Autorisatie binnen een federatief systeem Bij federatieve systemen kunnen autorisaties plaatsvinden in de vorm van een claim of assertie. Voor claimbased autorisatie is een Trust nodig tussen de service (applicatie) en een identiteiten server. De maat voor een Trust wordt vastgelegd met XACML. Autorisatie door het systeem zelf, zoals dit bij de andere referentiearchitecturen voor komt, is ook mogelijk. Beveiligde gegevensuitwisseling binnen een federatief systeem Netwerk beveiliging speelt een belangrijke rol, net als bij de referentiearchitectuur beperkt aantal domeinen. Genoemde gestandaardiseerde technieken SAML, XACML zorgen voor, in genoemde volgorde: 1) beveiligd netwerk en 2) een selectieve vrijgave van vertrouwelijke informatie.

23

Beperkingsregels

Voor de bekende referentiearchitecturen worden de beperkingregels in het feature-diagram gegeven. Het gebruik van beperkingregels is voor het eerst geïntroduceerd in het FODA document. Hiermee worden condities voor relaties tussen de features gegeven in de vorm van feature x heeft feature x‟ nodig of feature x sluit feature x‟ uit. Soms wordt er gesproken van constructieregels. Deze regels beperken de verzameling van alle mogelijke relaties van een gerichte acyclische graaf, het ID&AM feature-diagram. Geïsoleerd 1. Feature Valideren onder autorisatie heeft feature Verificatie onder authenticatie nodig. 2. Feature Verificatie onder authenticatie heeft feature Direct nodig. 2.1. Feature Direct heeft feature Persoon nodig. 2.2. Feature Persoon heeft feature Login nodig. 2.2.1. Feature Login heeft feature Naam nodig. 2.2.2. Feature Login heeft feature Wachtwoord nodig. 3. Feature Beheer heeft feature Provisioning nodig. 3.1. Feature Provisioning heeft feature Proces nodig. 3.2. Feature Provisioning heeft feature Account nodig. 3.3. Feature Provisioning heeft feature Onderhoud nodig. 3.4. Feature Onderhoud heeft feature Synchronisatie nodig. 3.4.1. Feature Synchronisatie heeft feature Domein nodig. 3.4.2. Feature Domein heeft feature Systeem nodig. 3.4.3. Feature Systeem heeft feature Repository nodig. 3.4.4. Feature Repository heeft feature Database nodig. 4. Feature Geïsoleerd onder Bereik sluit feature Aggregatie onder Onderhoud uit. 5. Feature Geïsoleerd onder Bereik sluit feature Netwerk onder Onderhoud uit. 6. Feature Geïsoleerd onder Bereik sluit feature AD onder Repository uit. 7. Feature Geïsoleerd onder Bereik sluit feature LDAP onder Repository uit. 8. Feature Geïsoleerd onder Bereik sluit feature Indirect onder Verificatie uit. 9. Feature Geïsoleerd onder Bereik sluit feature Uitwisseling onder Gegevens uit. 10. Feature Geïsoleerd onder Bereik sluit feature Propagatie onder Credential uit. Enkel domein 1. Feature Valideren onder autorisatie heeft feature Verificatie onder authenticatie nodig. 2. Feature Verificatie onder authenticatie heeft feature Direct nodig. 2.1. Feature Direct heeft of feature Systeem, Persoon of Machine nodig. 2.1.1. Feature Persoon heeft feature Login nodig. 2.1.1.1. Feature Login heeft feature Naam nodig. 2.1.1.2. Feature Login heeft feature Wachtwoord nodig. 3. Feature Domein onder Bereik heeft de feature Beheer onder Identiteit nodig. 4. Feature Beheer heeft feature Provisioning nodig. 4.1. Feature Provisioning heeft feature Proces nodig. 4.2. Feature Provisioning heeft feature Account nodig. 4.3. Feature Provisioning heeft feature Onderhoud nodig. 4.4. Feature Onderhoud heeft feature Synchronisatie nodig. 4.4.1. Feature Synchronisatie heeft feature Domein nodig. 4.4.1.1. Feature Domein heeft feature Systeem nodig.

24

4.4.1.2. Feature Systeem heeft feature Repository nodig. 4.4.2. Feature Synchronisatie heeft feature Netwerk nodig. 5. Feature Domein onder Bereik sluit feature Indirect onder Verificatie uit. 6. Feature Domein onder Bereik sluit feature Federatief onder Domein uit. Beperkt aantal domeinen 1. Feature Domein onder Bereik heeft feature Uitwisseling onder Gegevens nodig. 1.1. Feature Uitwisseling onder Gegevens heeft feature Netwerk onder gegevens nodig. 2. Feature Valideren onder autorisatie heeft feature Verificatie onder authenticatie nodig. 3. Feature Verificatie onder authenticatie heeft feature Direct nodig. 3.1. Feature Direct heeft of feature Systeem, Persoon of Machine nodig. 3.1.1. Feature Persoon heeft feature Login nodig. 3.1.1.1. Feature Login heeft feature Naam nodig. 3.1.1.2. Feature Login heeft feature Wachtwoord nodig. 4. Feature Domein onder Bereik heeft de feature Beheer onder Identiteit nodig. 5. Feature Beheer heeft feature Provisioning nodig. 5.1. Feature Provisioning heeft feature Proces nodig. 5.2. Feature Provisioning heeft feature Account nodig. 5.3. Feature Provisioning heeft feature Onderhoud nodig. 5.4. Feature Onderhoud heeft feature Synchronisatie nodig. 5.4.1. Feature Synchronisatie heeft feature Domein nodig. 5.4.1.1. Feature Domein heeft feature Systeem nodig. 5.4.1.2. Feature Systeem heeft feature Repository nodig. 5.4.2. Feature Synchronisatie heeft feature Netwerk nodig. 6. Feature Domein onder Bereik sluit feature Indirect onder Verificatie uit. 7. Feature Domein onder Bereik sluit feature Federatief onder Domein uit. Federatief 1. Feature Federatief onder Domein heeft feature Domein onder Bereik nodig. 2. Feature Federatief onder Domein heeft feature Uitwisseling onder Gegevens nodig. 3. Feature Valideren onder Autorisatie heeft feature Verificatie onder authenticatie nodig. 4. Feature Verificatie onder Authenticatie heeft feature Direct of Indirect nodig. 4.1. Feature Indirect onder Verificatie heeft feature Trust nodig. 4.2. Feature Indirect onder Verificatie heeft feature Netwerkprotocol nodig. 5. Feature Propagatie onder Credential heeft feature Federatief nodig. 6. Feature Federatief onder Domein heeft feature Uitwisseling onder verdeeld nodig. 6.1. Feature Uitwisseling onder Verdeeld heeft feature Afbeelding onder Uitwisseling nodig. 7. Feature Uitwisseling onder Gegevens heeft feature Netwerk nodig. 7.1. Feature Netwerk heeft feature Beveiligd nodig. 7.2. Feature Netwerk heeft feature Integer nodig. 7.2.1. Feature Integer heeft feature Validatie nodig. 7.3. Feature Netwerk heeft feature Vertrouwd nodig. 7.4. Feature Netwerk heeft feature Verantwoord nodig. 7.4.1. Feature Beveiligd heeft feature Encryptie nodig. 8. Feature Uitwisseling onder Gegevens heeft feature Beleid nodig. 8.1. Feature Beleid heeft feature Informatie nodig. 8.2. Feature Beleid heeft feature Controle nodig. 9. Feature Federatief onder Domein sluit feature Geïsoleerd onder Bereik uit.

25

Case studie.

Probleemstelling Decentraal usermanagement per module. Hierdoor ontstaat een te grote beheerslast voor de klanten die deze modules gebruiken. Mutaties op eenzelfde gebruikersaccount worden meerder malen herhaald en doorgevoerd. Doelstellingen 1) Een centraal usermanagement waarin een klant alle persoonsgegevens en de autorisatie kan onderhouden. 2) Centraal een overzicht van uitgedeelde autorisaties over alle modules heen per klant. Introductie De organisatie levert diensten op het gebied van HR aan klantorganisaties via een SAAS (Software As A Service) omgeving. Een set aan webapplicaties wordt gehost binnen één portal. Deze portal is onderdeel van een systeem dat voorziet in accountbeheer, autorisatie op de modules door middel van single sign-on. Elke module is een specialisatie binnen het gebied van HR. Maar er worden ook bepaalde functionaliteiten van bestaande complete HR systemen beschikbaar gesteld via deze portal. De modules zijn opzichzelfstaande systemen waarvan sommige systemen van oorsprong geen deel uitmaakte van de SAAS omgeving. De integratie van de modules binnen het systeem richtte zich op het operationeel maken van de modules binnen de portal. Klanten loggen een maal in op de portal en worden geautoriseerd voor bepaalde modules. Omdat de modules van oorsprong monolieten waren en ieder een eigen onderling afwijkend autorisatie en autorisatiemechanisme hanteerden is het centraal, eenmalig toekennen van rechten niet mogelijk. Zo komt het voor dat een beheerder voor het aanpassen van rechten voor een persoon alle modules langs moet om voor deze persoon de juiste instellingen op te geven. Het proces van aanmaken en aanpassen van identiteiten met bijbehorende rechten op systemen wordt het provisioning proces genoemd. Opmerking Een ID&AM systeem bestaat uit de twee volgende onderdelen: 1) Identiteitenbeheer, Identity Management (IDM), 2) Toegangsbeheer, Access Management (AM). De tekst hanteert deze twee begrippen. IDM en AM worden afzonderlijk of gezamenlijk als ID&AM besproken. IDM en AM kunnen afzonderlijk van elkaar een centrale- of decentrale architectuur bezitten binnen een ID&AM. Korte introductie van oude en nieuwe architectuur De meest kenmerkende eigenschappen: Oud: 1) Decentraal toekennen van rechten op module niveau, 2) Gebrek aan standaardisatie, 3) Afwijkende datastructuren voor autorisatie, 4) Diverse autorisatiemechanismen per module.

26

Feature modellering van een decentraal beheer systeem met n systemen en n Active Directory of database. Nieuw: 1) Centraal toekennen van rechten op basis van profielen, 2) Standaardisatie door gebruik van profielen, 3) Centraal en decentraal AM (Access Management), 4) Autorisatie op basis van profielen voor alle modules.

Feature modellering van een centraal beheer systeem met 1 systeem en 1 Active Directory of database.

De case Huidige (Oude) situatie. Probleemarchitectuur Een analyse van de huidige situatie wordt uitgevoerd aan de hand van een tak in het featurediagram dat uitkomt op het provisioning proces. Hier het feature-diagram beheer:

27

Deel van ID&AM feature-diagram voor beheer. Bladzijde 10. Beheer van identiteiten Werknemergegevens worden vastgelegd in de HR modules. Deze HR modules voorzien het centrale webaccount managementsysteem (portal) en de onderliggende modules van persoonsgegevens. De HR modules zijn bronsystemen. Dit proces is onderdeel van de features aggregatie en synchronisatie in het feature-diagram beheer. Met het centrale webaccount systeem worden accounts onderhouden met gegevens uit de HR bronsystemen. Onderdeel van de feature account onder provisioning. Het identificeert gebruikers en autoriseert toegang tot een van de onderliggende modules. Het biedt een beperkte identificatie service zoals het opvragen van persoonsgegevens, bepalen van een rol of functie met een identificerend persoonsnummer. Zelfservice Enkele modules leveren een UI voor Self Service. De gegevens worden dan decentraal opgeslagen. Provisioning Er is sprake van provisioning proces als er een gecontroleerd beheer van identiteiten en user accounts mogelijk is over de gehele levenscyclus. Aanmaken, veranderen en verwijderen. Accounts worden beheerd in het centrale webaccount beheer systeem. Persoonsgegevens komen uit de HR-bronsystemen en worden verspreid over de modules en decentraal opgeslagen. Het aanpassen van persoonsgegevens wordt geautomatiseerd of handmatig centraal uitgevoerd op de HR-bronsystemen. Deze gegevens bestaan uiteraard uit ADW gegevens (adres en woonplaats) maar zijn ook organisatorisch van aard. Zo is het bekend bij welke afdeling een personeelslid werk, hoeveel dienstverbanden deze heeft, of het een manager is van een afdeling, enz. Gegevens synchronisatie Via een batchverwerking komen persoonsgegevens uit het HR bronsysteem bij de modules terecht. Er is geen terugkoppeling vanuit de modules bij decentrale wijzigingen van persoonsgegevens of gerelateerde gegevens. Op het gebied van ID&AM onderhouden de modules eigen gegevens waarvan de structuren of onderlinge relaties buiten een module, of niet bekend zijn, of niet aansluiten, waardoor gegevensuitwisseling op dit vlak niet mogelijk is. Zolang deze gegevens binnen de modules beheerd blijven is dit ook geen probleem. Het probleem is echter dat hierdoor geen centraal geleide provisioning mogelijk is voor ID&AM. Wat weer resulteert in onnodig herhalende mutaties per module. En een onvolledig geautomatiseerde provisioning. Gegevens aggregatie Door genoemde onderling afwijkende datastructuren en afwezige relaties is het onmogelijk om vanuit een centraal systeem gegevens te aggregeren en de modules van alle informatie te voorzien. Autorisatie Autorisatiemethodieken verschillen per module. Enkele maken gebruikt van rollen en andere verlenen functionele en gegevens autorisatie op bepaalde middelen of beide. Het wel of niet toekennen van rechten bij, op rol gebaseerde autorisatie kan eenvoudig per groep. Een persoon wordt aan een rol gekoppeld en aan een rol worden rechten verleend. Het toekennen van rechten door autorisatie op middelen gaat per identiteit en is moeilijker te standaardiseren. Maar niet onmogelijk. Een binaire relatie tussen een persoon en een middel kan ook afgebeeld worden door een transitieve relatie van een persoon naar een middel via een rol. Hoe hiermee omgegaan wordt verschilt per module. Het bepalen van een rol of profiel voor autorisatie alleen is niet genoeg. Andere relaties zijn in gebruikt, een voorbeeld: of , . Bij de relatie wordt bijvoorbeeld gesteld dat een persoon een rol vervult voor een afdeling. Zo bestaan er nog een aantal relaties die niet gesynchroniseerd kunnen worden van een centraal systeem naar de modulen, of decentraal vanuit de modulen

28

naar een centraal systeem, omdat de elementen in een bepaalde relatie geen overeenkomstige afbeelding hebben in het codomein. De verschillende verzamelingen bevatten geen overeenkomstige elementen. Concreet voorbeeld: Als in een module een persoon geautoriseerd wordt op de rol HRManager en deze rol verder niet bekend is bij de andere systemen, dan kan deze relatie enkel binnen het domein van de module bestaan en niet daarbuiten. Conclusie. Aan de hand van voorgestelde meetmethodiek met feature-diagrammen kan gesteld worden dat het provisioning proces geen pad in het feature-diagram vindt door het ontbreken van een goede synchronisatie van benodigde informatie over alle dataopslag heen. De oorzaken zijn: 1) Er vindt geen volledige data-aggregatie plaats doordat moduleafhankelijke, relationele gegevensstructuren; of centraal ontbreken of niet gestandaardiseerd zijn en 2) Er geen terugkoppeling plaatsvindt vanuit de onderliggende modules naar een centraal ID&AM systeem bij decentrale wijzigingen. Volgens voorgestelde validatiemethodiek is het bereiken van een volledig pad in het featurediagram een voorwaarde voor verder evaluatie zodat niet meer ingegaan wordt op kwaliteitsaspecten en beïnvloedende factoren zoals geautomatiseerde batchverwerking of een beperking van het aantal communicatiepaden ter voorkoming van het rimpeleffect. De gegeven oplossing (Nieuwe situatie) Korte omschrijving Het nieuwe ID&AM systeem is een antwoord op de bestaande problematiek die zijn oorzaak vindt in de huidige architectuur. Hierbij hebben overwegingen als haalbaarheid, ROI (Return on Investement) en T2M (Time to Market) een belangrijke rol gespeeld. Een trade off tussen mogelijk, ideale oplossingen, genoemde belangen en gegeven beperkingen. Aanpassingen in relationele datastructuren van de HR bronsystemen moeten, bijvoorbeeld, backwards compatible blijven met hun historische data. Profielen Er is gekozen voor een functionele en structurele standaardisatie door middel van profielen. Profielen bevatten voorgedefinieerde eigenschappen. Het voorziet in de vastlegging van bepaalde datastructuren, die per module verschillend kunnen zijn. Hier wordt het genoemde probleem uit de eerdere validatie met ontbrekende relationele gegevensstructuren opgelost als centraal en decentraal de modules met profielen gaan werken. Beheer van identiteiten Identiteiten worden beheerd in het centrale IDM systeem. AM is zowel centraal als decentraal. De volgende requirements zijn opgesteld: Requirements Algemeen 1) De HR-bronsystemen zijn leidend voor de gegevens van medewerker- en managerprofielen, 2) Online medewerker- en managerprofielen geven standaard toegang tot de Online Modules, 3) Medewerker- en managerprofielen in een module krijgen de standaard functionele autorisatie van een identity, 4) De medewerker- en managerprofielen worden automatisch geactiveerd voor alle gebruikers van deze profielen, zowel in de portal als in de modules. De HR-bron-systemen 5) Leidende HR-basissystemen, 6) Leveren medewerkergegevens, 7) Leveren aan Online portal, a. OE (Organisatorische Eenheid) en Rol tabellen, b. Relatie MedeW/Rol/OE in de tijd,

29

c. Altijd volledige set, geen mutaties, 8) Uniform bericht bronsystemen, a. Berichtdefinitie omvat alle propositie sleutelgegevens. Geen gespecificeerde detail informatie mogelijk. Portal 9) Verwerkt automatisch werknemergegevens, 10) Users/Dienstverbanden, 11) Handelt uit dienst af, 12) Medewerker profielen/manager profielen op moduleniveau, 13) Kent automatisch medewerkerprofiel toe aan User/Mw, 14) Kent automatisch managerprofiel toe aan User/Mw, 15) Opslag UM-gegevens Rol/OE/Toewijzing/tabellen, 16) Web services ten behoeve van de uitvraag door andere modules. Modules 17) Hebben eigen medewerker- en managerprofielen op modulefunctie niveau, 18) Hebben eigen autorisatie tabellen Rol/User/OE, 19) Onderhouden de eigen autorisatietabellen via de Online UM Webservices, 20) Automatisch proces, 21) Handmatige aanvullingen blijven mogelijk. Validatie Allereerst wordt de vraag beantwoord of met de gegeven oplossing de voorwaarde voor een verder evaluatie wordt waargemaakt? -Om deze vraag te beantwoorden wordt nagegaan of met de oplossing een volledig pad in het feature-diagram te vinden is. Beheer van identiteiten Het centrale webaccount management systeem is opgewaardeerd naar en volwaardige identity server die gevoed wordt vanuit de HR-bronsystemen en staat in dienst van de modules op het gebied van ID&AM. Zelfservice Deze feature is mogelijk doordat gegevensuitwisseling van en naar de modules een feit is. Provisioning Het provisioning proces vindt plaats tussen de HR-bronsystemen en het IDM systeem dat een onderdeel is van het systeem Online portal. Aanmaken, wijzigen en verwijderen van identiteiten wordt afgestemd op het IDM vanuit de HR- bronsystemen. Wijzigingen komen van de HR-bronsystemen (Req 5, 6, 7, 9) en worden verwerkt door het IDM systeem (Req 9, 10, 11). De gegevens worden centraal opgeslagen (Req 13, 14, 15) en beheerd. AM(Access Management) is centraal en decentraal(Req 18, 19, 21). Mutaties op profielen van identiteiten worden doorgevoerd naar alle modules(Req 17, 18). Gegevens synchronisatie Een centralegegevensopslag is vanuit twee richtingen gesynchroniseerd: Medewerkergegevens vanuit de HR bronsystemen en autorisatie gegevens vanuit de modules. Door het gebruik van profielen waarin de nodige relatiestructuren zijn gedefinieerd is het voor de modules mogelijk wijzigingen decentraal op te nemen of met de centrale data opslag te synchroniseren. De relatiestructuren zijn gebonden aan de volgende structuur: , (Req 7 b). De relatie is bijvoorbeeld niet te synchroniseren vanuit de modules. Dit is geen probleem en zelfs niet wenselijk omdat deze gegevens zijn vastgelegd in de HR bron systemen. De vraag of synchronisatie afdoende is hangt af van de definitie van een organisatorische eenheid. Is een organisatorische eenheid een databestand in de volgende relatie: ? De frequentie van synchronisatie is niet een van de requirements. Het is ook niet uitgesloten dat synchronisatie HR-bronsysteem afhankelijk is. Er zijn HR-bronsystemen waarbij gegevens periodiek „geupload‟ worden naar een centrale server. Realtime provisioning is hierdoor uitgesloten.

30

Gegevens aggregatie Is het mogelijk om specifieke module gerelateerde gegevens op te vragen? De modules kunnen werken met profielen (Req 3,4). Specifieke gegevensrelaties, beschreven door profielen, zijn onderling uitwisselbaar en daardoor op te vragen. Het ID&AM systeem aggregeert samenhangende gegevens vanuit de centrale data opslag die gesynchroniseerd wordt met de HR bronsystemen. Door de vertraagde synchronisatie kunnen onjuiste gegevens gehanteerd worden. De relatie wordt niet vastgelegd in een profiel maar is wel op te vragen. Autorisatie Autorisatie van identiteiten/personen gaat op basis van de relatie . Dataverzamelingen uit deze relatie worden door de modules zelf centraal en decentraal onderhouden (Req 18, 19) waardoor een gedetailleerde autorisatie binnen de modules mogelijk is. Eerste conclusie Er is een volledig pad in het feature-diagram gevonden waarmee een verdere validatie op grond van gestelde kwaliteitseisen mogelijk is. Een centraal ID&AM lijkt te worden waargemaakt vanuit de optiek van een beheerder door: 1) Inzet van profielen of rollen voor groepsautorisatie. 2) Provisioning en data-aggregatie vanuit een van de bronsystemen naar het ID&AM systeem. 3) Mechanisme voor publicatie van functionele autorisatie gegevens vanuit de modules naar het centraal ID&AM systeem en vice versa. Wat is de waarde van deze conclusie? De validatie is uitgevoerd volgens een gestructureerde methodiek die systematisch is uitgevoerd. De validatiemethodiek gaat uit van een feature-diagram, opgesteld vanuit het perspectief onderhoud. Het validatie proces start vanuit de top van het feature-diagram en volgt de richting van verbonden pijlen naar onderliggende features. Onderzocht wordt of de oplossing aan elke verplichte feature voldoet of aan een van de optionele features. De validatie stopt als er geen onderliggende laag meer wordt gevonden of als een van de benodigde features niet wordt gehaald. Bij het niet halen van een feature wordt nagegaan of opgestelde feature-diagram klopt. Stap twee van het validatie proces. Een verdere validatie wordt als volgt voorgesteld: Modelleer gegeven oplossing in een featurediagram en voeg een weging toe aan elke feature. Het gewicht van de wegingen is afhankelijk van gestelde doelen en requirements. Hiermee wordt een antwoord gezocht op de vraag: “Wat is de kwaliteit van de oplossing die in stap 1 is waargemaakt?”.

31

Afgeleid feature-diagram voor de gegeven architectuur uit het ID&AM feature-diagram. Bladzijde 10. Het feature-diagram is geannoteerd met een weging waarbij aangegeven of een feature belangrijk is of niet zo belangrijk. Deze weging is afgeleid uit de gegeven requirements. Verder is de feature Domein voorzien van een cardinaliteit 1. Hiermee wordt bedoeld dat het in deze oplossing gaat om een synchronisatie van gegevens over één domein. Een centrale dataopslag, volgens doelstelling 1: Een centraal usermanagement waarin een klant alle persoonsgegevens en de autorisatie kan onderhouden. Het provisioning- en deprovisioning proces In het provisioning- en deprovisioning proces is het aanmaken, aanpassen en verwijderen van identiteiten even belangrijk. Omdat het synchroniseren van medewerkergegevens van de HR bronsystemen naar het ID&AM systeem niet real time is, en er geen requirement beschreven is dat de synchronisatie van de modules naar het ID&AM systeem real time plaats vindt, is deze feature ook niet in het diagram opgenomen. Hierdoor kunnen in het ID&AM systeem identiteiten bestaan die of een andere invulling hebben gekregen of niet meer mogen bestaan. Toegang tot de modules is dan op basis van de oude gegevens. Dit lijkt een belangrijke constatering omdat het doel van ID&AM (het toegang verlenen aan geïdentificeerde personen of systemen van systeemfuncties of bronnen op basis van persoonlijke of groepsgewijze autorisatie) afwijkt van de realiteit omdat een provisioning proces pas na enige tijd voltooid wordt. Concreet betekent dit dat personen of systemen ongeoorloofd toegangsrechten houden of wel of niet krijgen voor een bepaalde tijd. Een centraal usermanagement Een centraal usermanagement waarin een klant alle persoonsgegevens en de autorisatie kan onderhouden is wel de belangrijkste doelstelling in deze case. De HR bronsystemen bevatten alle persoonsgegevens. Het provisioning proces synchroniseert vanuit de HR bronsystemen een deel van de persoonsgegevens en in de HR-bronsystemen vastgelegde relaties als naar het ID&AM systeem (Req 6, 7). Provisioning en deprovisioning wordt geactiveerd vanuit de HR bronsystemen. Een centraal usermanagement systeem wordt hiermee niet bereikt omdat het onderhoud van persoonsgegevens gescheiden plaats vindt van het ID&AM systeem waardoor een decentrale architectuur ontstaat.

32

Usermanagement en provisioning vanuit de HR-bronsystemen geeft het ID&M systeem een decentrale architectuur. Relaties als voor autorisatie doeleinden worden centraal in het ID&AM systeem beheerd via het portal systeem (Req 12) en gedelegeerd naar de modules die deze gegevens ook weer decentraal vastleggen. Usermanagement vanuit gebruikersoptiek is gecentraliseerd voor autorisatiedoeleinden. Doormiddel van profielen worden aanpassingen op rechten van een gebruiker naar de modules gedelegeerd. Beheer is hierdoor eenmalig en centraal geregeld. Een centraal usermanagement wordt voor beheerders van het systeem voor een deel wel waargemaakt maar de onderliggende architectuur blijft hopeloos verdeeld! Het accent van deze conclusie ligt dus in het feit dat de doelstelling was: „een centraal usermanagement‟. In plaats van een „centraal identity management‟. Deze decentrale opstelling van het onderliggende systeem voor usermanagement vanuit de HR-bronsystemen en portal heeft ook zijn weerslag op genoemde vertraging in het provisioning proces. Systeem integratie Opvallend is het ontbreken van niet functionele kwaliteitseisen. In de bijlage standaard producten worden voorbeelden gegeven van standaard oplossingen en het succesvol inzetten van standaard oplossingen. Toepassing van software engineering principes als het voorkomen van het rimpeleffect door Information hiding, beperking van het aantal communicatie paden en inzet van mediators, maakt een keus voor een standaard oplossing mogelijk. Helaas wordt er maar al te vaak voortborduurt op bestaande architecturen, omdat afhankelijkheden tussen systeemcomponenten elkaar onderling in de greep houden. Concreet in deze case houdt dit in dat 1) Op het gebied van user management alle modules decentraal van medewerkergegevens voorzien blijven vanuit de HR bron systemen. 2) Er geen uitdrukking wordt gegeven aan nieuwe technieken als ADFS of abstractie van authenticatie en autorisatie mechanismen om logica in de onderliggende modules te abstraheren waardoor toekomstige wijzigingen niet meer van invloed zijn op de bestaande code. Dit laatstgenoemde principe is bijvoorbeeld terug te vinden in het OSI model waarbij de complexiteit van netwerkverkeer volledig is geabstraheerd. Was de oorzaak van het probleem niet een matige integratie van de afzonderlijke modules? Kort overzicht Een centraal usermanagement

Beheer +-

Een centraal ID&AM

++

Provisioning

+-

Data-standaardisatie

++

Architectuur --

Overweging Gegevens van medewerkers worden in de HR modules onderhouden maar ook in de afzonderlijke modules. Binnen de modules wordt nog altijd beheer uitgevoerd op lokale medewerkergegevens. [-] -Voor een beheerder is het toekennen van rechten doormiddel van rollen en profielen een eenmalige actie over alle modules heen. [+] Identiteitsgegevens zijn centraal op te vragen door alle modules. [+] Toegangsbeheer vindt decentraal plaats binnen de afzonderlijke modules, identiteiten server en de HR bronsystemen. [-] +Het geautomatiseerd delegeren van wijzigingen op identiteitsgegevens naar onderliggende modules en dataopslag vindt vertraagd plaats waardoor in principe ID&AM op onjuiste gegevens gebaseerd kan zijn. [-] Door data-standaardisatie is provisioning mogelijk. [+] ++ De inzet van profielen voorziet in standaardisatie voor gegevensopslag en gegevensuitwisseling. Hierdoor is het delegeren van wijzigingen op een deel van medewerkergegevens voor toekenning van rechten mogelijk al vindt dit niet realtime plaats.[+] -- niet goed, +- matig, + redelijk, ++ goed, [+] pluspunt, [-] minpunt

33

Validatie uitkomst Aandachtspunten: 1) 2) 3) 4)

Realtime provisioning, Decentrale ID&AM architectuur naar een centrale ID&AM architectuur, Systeem integratie, Verminderd aantal communicatiepaden.

Pluspunten: 1) Groepsgewijze autorisatie, 2) Centraal beheren van identiteiten en toekennen van rechten (usermanagement), 3) Standaardisatie in gegevensuitwisseling. Overwegingen 1. Een standaardisatie voor gegevensuitwisseling is bereikt door de inzet van profielen. Met profielen is het net als bij het gebruik van rollen, mogelijk om groepsgewijs rechten toe te kennen. Er is echter geen plaats voor een gedetailleerde informatie-uitwisseling buiten de vooraf gedefinieerde profielen. Een veel krachtiger mechanisme om identiteitinformatie te delen (dit kan zelf realtime waardoor het provisioning proces strek vereenvoudigd) is met SPML. SPML is een XML gebaseerde standaard ter ondersteuning van het provisioning proces tussen verschillende systemen op verschillende domeinen of zoals in deze case tussen de modules, HR-bronsystemen en de portal. Hiermee kunnen ook onderling verschillende datastructuren op elkaar afgebeeld worden om zo attributen van identiteiten tussen de verschillende systemen te delen. Het geschetste probleem van niet op elkaar af te beelden relaties tussen de systemen in voorgaande analyse wordt hiermee opgelost met behoud van gedetailleerde informatie. 2. Door het decentraal beheer van autorisatiedata is een provisioning nodig naar alle modules binnen het portal systeem. Relaties als bijvoorbeeld worden door de modules zelf onderhouden. Een abstractie van het autorisatiemechanisme en het verplaatsen van het onderhoud naar een centraal systeem zal een provisioning proces naar de modules overbodig maken en het beheer vereenvoudigen. De abstractie houdt in dat de modules op de gangbare wijze blijven autoriseren maar dit via een interface doen, die de implementatie details voor de modulen verbergt. De autorisatie gaat in dit geval via een centraal assertie systeem op basis van SAML en XACML. Ad. Punt 1 maakt decentraal gegevensbeheer binnen elke module mogelijk. Punt 2 Voorziet in de communicatie tussen de modules en een gecentraliseerd autorisatiemechanisme. Beide punten sluiten elkaar wel uit. Het is een keuze voor Punt 1 of Punt 2 of geen van beide. SPML en SAML zijn actief in federatieve systemen. De referentiearchitectuur federatief geeft aan dat SPML gebruikt wordt bij systemen met een verdeeld aantal domeinen en meer dan 1 dataopslag. Federatieve systemen. Het is hier ook voor bedoeld. Maar het decentrale karakter van dit enkel domein systeem en het decentrale beheer van autorisatiedata rechtvaardigt het gebruik van SPML. Het provisioning proces synchroniseert data over meerder systemen en dataopslag heen. Het decentrale databeheer maakt het domein verdeeld. De definitie van de features in het feature-diagram voor dit systeem luidt dan: Synchronisatie via een enkel verdeeld domein met meerdere systemen naar één dataopslag per systeem. Dit is geen algemeen bekend en aanvaarde ID&AM architectuur. Het geeft al aan dat de gegeven oplossing moeilijk te plaatsen is.

34

Afbeelding van één enkel verdeeld domein met n systemen en één dataopslag per systeem. Aanbeveling 1) Overweeg het gebruik van SPML voor gedetailleerde uitwisseling van identiteitsgegevens en realtime provisioning. Samenvatting Kennis is expliciet gemaakt door het ID&AM oplossingsdomein te modelleren met featurediagrammen. Dit is een momentopname en er kan gesteld worden dat met de tijd het oplossingsdomein zeker zal veranderen op het gebied van ID&AM. Het is dus van belang bij een toepassing van voorgestelde validatiemethodiek dat het feature-diagram meebeweegt met de gaande ontwikkelingen op het gebied van ID&AM. De voorgestelde validatiemethodiek houdt rekening met veranderingen. Eventuele tekortkomingen in de modellering worden gesignaleerd omdat de validatiemethodiek voorschrijft dat in stap 1 nagegaan wordt of de feature-diagram geen gebreken vertoont. De validatiemethodiek voorziet in een raamwerk voor een gestructureerde analyse zoals is aangetoond in de case.

35

Conclusie De onderzoeksvraag De onderzoeksvraag die aan dit verslag ten grondslag lag is de vraag: Hoe een gegeven ID&AM oplossingarchitectuur te beoordelen? Deze vraag ontstond uit de opdracht: Beoordeel een gegeven ID&AM architectuur. Algemeen gezien voldoet een oplossing als het gestelde doelen waar maakt of bepaalde problemen wegneemt. Voor de opdracht Beoordeel een gegeven ID&AM architectuur zou het voldoende zijn om doelstellingen en requirements te achterhalen om vervolgens na te gaan of de nieuwe architectuur aan deze eisen voldoet. In zekere zin is dit, wat validatie methoden als ATAM doen. Voor deze aanpak is niet gekozen. De opdracht is breder uitgelegd door op zoek te gaan naar een antwoord op de vraag: Wat is een goede ID&AM architectuur, onder welke omstandigheid en hoe ziet deze eruit? Met de verworven kennis is de gegeven architectuur op zijn merites beoordeeld. Deze aanpak heeft geleid tot een onafhankelijk onderzoek. Onafhankelijk van doelstellingen en requirements die op hun beurt kunnen voortvloeien uit bestaande situaties en belangen. Gekozen is voor een methodiek waarbij het oplossingsdomein bestudeerd wordt. En te modelleren. Dit model is een weergave van het oplossingsdomein waar de gegeven en te beoordelen oplossingsarchitectuur in terug te vinden moet zijn. Validatiemethodiek De voorgestelde validatiemethodiek wordt hier kort herhaald.

Flowchart validatiemethodiek. De twee fasen: Fase 1. Het beslissingselement in flowchart.”Oplossing heeft pad in feature-diagram”, Fase 2. Het proces element in de flowchart. ”Kwaliteitanalyse”. Aannames en veronderstellingen 1) Het is mogelijk om het volledige oplossingsdomein te modelleren met een featurediagram, 2) De uitkomst fase een, validatiemethodiek is niet afhankelijk van een uitvoerend persoon, 3) De uitkomst fase een blijft gelijk bij meerdere uitvoeringen binnen een redelijk termijn.

36

4) De uitkomst fase twee is impliciet afhankelijk van kennis en kunde uitvoerend persoon. Conclusie De conclusie kan dus een antwoord zijn op de vraag of de gekozen richting de juiste was? Welke uitdagingen zijn overwonnen en waren deze te voorkomen door voor een andere evaluatiemethode te kiezen? Zoals al is aangegeven bestaan er verschillende methoden om een architectuur te beoordelen. Belangrijk verschil met ATAM is het werken vanuit een volledig gemodelleerd domein. Bij FODA wordt domeinkennis expliciet gemaakt in de vorm van een feature-diagram. Bij ATAM wordt deze kennis impliciet aanwezig verondersteld in de vorm van een architect die in staat is om bepaalde kwaliteitsaspecten te beoordelen. Een verkenning van het oplossingsdomein begint nadat aandachtspunten bekend zijn. In deze zin lijkt de keuze voor ATAM minder inspanning te gaan kosten, omdat slechts die gebieden onderzocht worden die strikt noodzakelijk zijn voor de evaluatie. Aan de andere kant is een volledig domeinonderzoek ontzettend leerzaam en levert een herbruikbaar referentiemodel op met een geldigheid binnen een redelijke tijdsspanne. De voorgestelde evaluatiemethodiek schrijft dan ook voor dat het referentiemodel zelf ook ter discussie moet staan en mee evalueert met de gaande ontwikkelingen binnen het ID&AM domein. De hoe vraag is beantwoord door het uitwerken van voorgestelde evaluatiemethodiek en het toepassen daarvan. Hiervoor is een ID&AM domeinonderzoek uitgevoerd met een FODA feature-diagram als resultaat. De voorgestelde methodiek is toegepast en beschreven in het voorbeeld case. Een antwoord op de vraag of toepassing van deze methodiek de juiste was wordt in dit verslag niet gegeven. Wel wordt de methodiek gepositioneerd ten opzichte van een bekende evaluatiemethode, ATAM en aangetoond dat de methodiek toepasbaar is. Wat is de scope van het onderzoek? Wat niet binnen het bereik van dit verslag valt is een empirisch onderzoek van de verschillende architectuurevaluatiemethoden en ook niet een wetenschappelijk bewijs voor correctheid van voorgestelde validatiemethodiek. Om de kwaliteit van de voorgestelde validatiemethodiek te kunnen beoordelen zou voor dezelfde case een ander gerenommeerde evaluatiemethode ingezet kunnen worden om hierna de uitkomsten te vergelijken. De vraag is dan of de verschillende methodes tot dezelfde conclusie leiden? Een andere vraag is of de inzet van de validatiemethodiek altijd tot hetzelfde resultaat leidt bij verschillende uitvoerende personen? Met andere woorden: In welke maat is aanwezige kennis bij de uitvoerende personen doorslaggevend voor de uitkomst? Het accent bij dit onderzoek ligt in de bestudering van ID&AM architecturen en het modelleren van een feature-diagram dat weer als input dient voor de evaluatiemethodiek. Het featurediagram zelf, is getoetst door, voor een aantal in de literatuur beschreven en gerenommeerde referentiearchitecturen, na te gaan op deze uit het feature-diagram te herleiden zijn. Uitkomst van deze studie is: 1) Zo goed als volledig domeinonderzoek van ID&AM, 2) Toetsing van feature-diagram aan de hand van referentiearchitecturen, 3) Voorstel validatiemethodiek, 4) Positionering van validatiemethodiek ten opzichte van ATAM, 5) Uitgebreide validatie van een gegeven ID&AM architectuur volgens de methodiek. Deze studie bevat niet: 1) Een wetenschappelijk bewijs van correctheid voor validatiemethodiek, 2) Empirisch onderzoek naar de verschillende architectuurevaluatiemethoden. Evaluatie van toegepaste aanpak Het gebruik van een feature-diagram dat in principe een valide oplossing in zich heeft, geeft structuur en houvast tijdens het evaluatieproces. Onomstotelijk kan vastgesteld worden of noodzakelijke elementen en onderlinge afhankelijkheden tussen de elementen aanwezig zijn in het te beoordelen systeem. Nadeel is de initiële inspanning om tot een zo goed als volledig feature-diagram te komen. Ook blijft bij de toegepaste aanpak in tweede instantie het beoordelingsvermogen van de beoordelaar doorslaggevend voor het eindresultaat.

37

Ad. Laatste opmerking wordt ingegeven doordat: 1) De beoordelaar moet per feature aangeven wat de kwaliteit van de feature is binnen de oplossing. Tijdens de evaluatie (zoals deze beschreven is in de case) werd bijvoorbeeld verondersteld dat de doorlooptijd van het provisioning proces het beginsel van ID&AM raakt, namelijk: het toegang verlenen aan geïdentificeerde personen of systemen van systeemfuncties of bronnen op basis van persoonlijke of groepsgewijze autorisatie. Aangetoond is dat een vertraagd provisioning proces dit genoemde beginsel niet mogelijk maakt terwijl deze feature oorspronkelijk niet eens tot het pakket van eisen behoorde. Het was aan de beoordelaar om de sterke en zwakke punten in de gegeven oplossing op te sporen en te herkennen, 2) Het ID&AM FODA is onderdeel van een breder spectrum van verschillende software architecturen. Zo wordt de doorlooptijd van een provisioning proces mede bepaald door kwaliteitsaspecten performance en beschikbaarheid. Performance en beschikbaarheid zijn bekende eigenschappen. [5] beschrijft bepaalde tactieken om deze eigenschappen in een systeem te kunnen bereiken. Voor beschikbaarheid zijn dit bijvoorbeeld de eigenschappen: Fout detectie, herstellen, herstart, en voorkomen. Een open vraag blijft of de voorgestelde validatiemethodiek terug te brengen is naar stap 1 door een complete modellering van bestaande architecturen waarbij ID&AM een onderdeel is? Wat is hier aan te doen? Om de invloed van de beoordelaar op het resultaat te verminderen kan het ID&AM featurediagram geplaatst worden binnen een feature-diagram met een breder perspectief zodat bekende referentiearchitecturen met eigenschappen als performance, beschikbaarheid (maar ook andere eigenschappen) mee gaan wegen in stap 1 van voorgestelde validatiemethodiek.

38

Begrippenlijst

Hier worden de in de tekst gebruikte ID&AM begrippen en alle feature-diagram elementen verklaard. Aanmaken Onderdeel van het provisioning proces. Aanmaken van een identiteit binnen een IDM systeem. Aanpassen Onderdeel van het provisioning proces. Wijzigen van identiteitsgegevens. Account Een set van gegevens/elementen waarmee een gebruiker zichzelf kan identificeren en de toegangsrechten bepaald kunnen worden. Accountability Het onderkennen en volgen van regels zoals deze zijn afgesproken voor een bepaald protocol. AD Active Directory is een mechanisme om persoonsgegevens centraal op te slaan. Active Directory Federation Services (ADFS) ADFS integreert het gebruik van digitale identiteiten tussen verschillende organisaties. Met ADFS kunnen verschillende organisaties digitale identiteiten op een veilige manier met elkaar delen. Waarbij elke organisatie alleen die identiteiten beheert waar zij eigenaar van zijn. ADFS komt voort uit Active Directory (AD), dat ten doel heeft om persoonsgegevens centraal op te slaan en weer toegankelijk te maken. Afbeelding Onderdeel van gegevensuitwisseling. Aaneengesloten IDM systemen kunnen zo gegevens uitwisselen in verschillend formaat. Afdrukken Heeft ten doel om elektronische gegevens buiten een computersysteem vast te leggen en eventueel uit te wisselen. Aggregatie Ophalen en samenvoegen van gegevens uit verspreide dataopslag. Algemeen Algemeen heeft betrekking op een gedeelde eigenschap zoals een rol of profiel. Assertie Een Assertie bevat informatie over een identiteit en de bijbehorende attributen. Assertie is een onderdeel van SAML. Asymmetrisch Een encryptie methode. Voor asymmetrisch encryptie geldt dat de encryptie- en decryptie sleutels verschillen en alleen de decryptiesleutel verborgen blijft. Zie ook encryptie.

39

Attribuut Een eigenschap van een identiteit. Auditing Monitoren van; aanmaken, aanpassen en gebruik van identiteitsinformatie volgens bepaalde garanties. Authenticatie Authenticatie is de identiteit van een persoon of systeemobject verifiëren. Authenticatiesleutel Een set van gegevens om de identiteit van een object of persoon vast te stellen. Autorisatie Het verlenen van bepaalde rechten op basis van een vastgestelde identiteit. Gegevens autorisatie en functionele autorisatie vindt plaats op basis van systeembronnen en identiteit, op basis van profielen of rollen, en kan ook claim based zijn. Op het gebied van beveiliging kan onderscheid gemaakt worden tussen decentrale autorisatie en centrale of federatieve autorisatie. Met decentrale autorisatie wordt autorisatie op module of applicatie nivo bedoeld op basis van bronnen, profielen en rollen. Met centrale of federatieve autorisatie wordt claim based autorisatie bedoeld. Deze methode is gevoelig voor beveiligingskwesties van communicatie over netwerken heen. Autorisatie gaat op basis van een identiteit. Voor claimbased autorisatie is een trust nodig tussen de service (applicatie) en een identiteiten server. De maat voor een Trust wordt vastgelegd met XACML. Autorisatielogica op broncode Imperatieve autorisatie. Ook hier gaat het om een verfijnde autorisatie logica in code, maar niet op rol. Zo kan de vraag ontstaan of de principal tot een leeftijdscategorie behoort of werkt op een bepaalde afdeling. Beheer Onderdeel van IDM. Informatie over een identiteit wordt beheerd binnen een IDM systeem. Beleid Uitvoering van vastgestelde regels. Beperkte toegankelijkheid Functionele- en gegevensautorisatie beperken de toegang tot modules, functies en gegevens. Hiervoor is een succesvolle identificatie nodig. Webapplicaties die van deze methode gebruik maken zijn per definitie niet publiek. De beveiliging van publieke webapplicaties wordt anders voorgesteld. Firewall beperken de toegang op basis van berichtenbron en doel poorten. Voor een architectuur met publieke webapplicaties is het niet mogelijk om te selecteren op de bron[5]. Om selectief te beveiligen kan de architectuur opgedeeld worden in een publiek Internet deel en een privé netwerk door toepassing van een DMZ. Deze staat dan tussen het Publieke Internet deel en een firewall die het privé netwerk afschermt. Een combinatie architectuur met deze methodieken en autorisatie is ook denkbaar. Bereik

40

Begrenzing van een systeem. Bestandsautorisatie. Autorisatie op bestanden met user credentials met ADF of LDAP Beveiligd Een ID&AM system kent vele vormen van beveiliging. Netwerkbeveiliging via encryptie en gedefinieerde protocollen. Validatie van dataverkeer. Beleidsregels voor informatieuitwisseling.

Biometrie Een methode om de identiteit vast te stellen aan de hand van een lichamelijke eigenschap.

Bron In dit kader is een bron onderdeel van autorisatie. Een systeembron. Systeembronnen zijn middelen als webpagina‟s en databases of digitale bestanden. Cache Een opslagmechanisme waarvan de gegevens bewaard blijven zolang de machine waarop de cache bestaat actief is. Certificaat Een elektronisch beveiligt identificatiebron. Een ontvanger van een digitaal bericht vertrouwt de zender van het bericht. Checksum Methode om te controleren of gegevens origineel zijn en niet gemanipuleerd.

Claim Een verzoek tot toegang op systeembronnen. Code Een set van instructies om een programma mee te schrijven. Controle

41

Een onderdeel van beleid. Nagaan of en hoe opgestelde beleidsregels uitgevoerd worden. Credential Bepaalde eigenschappen die bij een account horen. Data Elektronische gegevens. Database Persistente dataopslag van aan elkaar gerelateerde gegevens.

Data integriteit Gegevens zijn precies gelijk als op het moment dat deze verzonden zijn. Validatie technieken om te controleren of data niet is gemanipuleerd zijn bijvoorbeeld: Checksum encoding en de toepassing van hash results. Declaratieve vraag op classes en methoden. Hierbij wordt geautoriseerd op de aanroep van objecten van een bepaald type en op de aanroep van bepaalde methoden. Het recht om een object te benaderen of om een methode te activeren wordt bepaald door te associëren met een principal die bijvoorbeeld een bepaald rol als eigenschap bezit. Declaratief Functionele autorisatie die op het moment van codecompilatie wordt vastgesteld. Dit in tegenstelling van runtime autorisatie. Delegatie Een gedelegeerde authenticatie die voorkomt bij de impersonata techniek. DeMilitarized Zone Een DMZ is het gedeelte van een persoonlijk netwerk dat via een firewall verbonden is met het Internet. Het wordt ingezet om een verbinding met het Internet mogelijk te maken en andere delen van het persoonlijke netwerk af te schermen van deze onbeveiligde verbindingen.

Deprovisioning Het verwijderen of ongedaan maken van een identiteit uit het complete systeem. Een goede en juiste deprovisioning voorkomt dat identiteiten ten onrechte geautoriseerd worden als deze identiteit is verwijderd.

42

Digitaal bestand Een systeembron waar toegang toe verleend kan worden. Direct Directe verificatie van een identiteit. In tegenstelling tot indirecte verificatie waarbij op basis van vertrouwen een door een derdepartij IDM systeem geïdentificeerd object geaccepteerd wordt. Domein Gesloten systeem. Eigenschap Onderdeel van een principal. Een principal kan een of meerdere eigenschappen bezitten. Encryptie De techniek voor cryptografie bevat twee procedures, een voor encryptie en een voor decryptie. Er zijn twee cryptiesystemen: symmetrisch en asymmetrisch. Voor symmetrisch geldt dat de encryptie- en decryptie sleutels hetzelfde zijn en hierdoor beide verborgen moeten blijven. Voor asymmetrisch geldt dat de encryptie- en decryptie sleutels verschillen en alleen de decryptiesleutel verborgen blijft. Exception handling Een correcte afhandeling van onverwachte fouten voorkomt dat gedetailleerde systeem informatie de gebruiker kan bereiken. Informatie als SQL statements met tabelnamen en kolom namen mogen bijvoorbeeld niet zichtbaar worden als er een fout ontstaat.

Expliciete rol controle voor verfijnde autorisatie. Een toevoeging op Declaratieve autorisatie. Hierbij wordt nagegaan of een principal lid is van een bepaalde groep of een bepaalde rol bezit. Deze methode is geschikt om autorisatie logica te verfijnen. Zo kan het bijvoorbeeld voorkomen dat bepaalde limieten voor de uitvoering van een businessproces vastgelegd zijn per rol. Voor de verschillende rollen is een onder of bovengrens bepaald en als deze wordt overschreden zal nagegaan worden of de principal gerelateerd is aan een andere rol. Federatief Set van aaneengesloten IDM systemen. Firewall Een firewall houdt ongewenste communicatie tegen. Het staat tussen het Internet en het persoonlijke- of bedrijfsnetwerk. Functioneel Functionele autorisatie is toegang verlenen tot klassen en methoden. Geheugen Opslag mechanisme van een computer.

43

Geïsoleerd Beperkt ID&AM systeem met een authenticatie en autorisatie mechanisme binnen een enkel domein zonder gegevens uitwisseling naar andere systemen. Hasresult Validatie methode om een eventueel gebrek van gegevens te detecteren. Identificatie en verificatie De methodes voor identificatie en verificatie kunnen onderverdeeld worden in zwakke en sterke identificatie en verificatie. Richtlijnen voor deze indeling zijn eigenschappen als encryptie. Een voorbeeld voor zwakke identificatie is het gebruik van login procedures zonder encryptie en input validatie. Identiteit Een identiteit is een unieke representatie van een persoon of systeemobject. Een persoon kan meerdere identiteiten bezitten[39].

Identiteitsafbeelding Identiteitsafbeelding is een op een weergave van identiteitsinformatie zodat verschillende IDM systemen gegevens onderling kunnen delen. Identity & Access Management Identity management is het beheer van een digitaal opgeslagen entiteit met bepaalde eigenschappen om deze eigenschappen vast te kunnen leggen en om deze weer op te vragen zodat, tijdens een authenticatie procedure, bepaald kan worden wie een persoon of programma is. Identity management is iets anders dan usermanagement. Bij identity management gaat het om het bepalen van een identiteit. Bij usermanagement gaat het om het vastleggen en beheren van persoonsgegevens in een bredere zin zoals adresgegevens. Access management is het bepalen van rechten die horen bij een vastgestelde identiteit. Een geïdentificeerd persoon of programma wordt toegang verleend of geweigerd aan bepaalde functies of bepaalde gegevens. Identity & Access Management ook wel als aangeduid met de termen Authenticatie en Autorisatie.

44

Met authenticatie wordt vastgesteld of een identiteit (persoon of proces) is wie het beweert te zijn. Het doel van autorisatie is vaststellen of een identiteit recht heeft op bepaalde systeembronnen (data) en/-of bepaalde systeemfuncties (programma‟s en processen).

(Claim- based) Identity & Access Management Een claim vertelt iets over een entiteit die het onderwerp is van de claim. Een claim kan bijvoorbeeld zijn dat een identiteit het recht heeft om een bestand te lezen. Een identity provider behandelt claims. Een van de elementen die een claim valide maken is het vertrouwen tussen de identity server en het systeem dat de claim accepteert, de vertrouwende partij. Claims kunnen heel gericht zijn zoals het opvragen van de leeftijdsgroep van een identiteit zonder meer informatie uit te wisselen als leeftijd, geboortedatum enz. Dit verhoogt de beveiliging van persoonlijke informatie. Voordeel van claim-based identity en access management is de ontkoppeling van authenticatie en autorisatie specifieke logica in elk systeem door deze te vervangen door een standaard en afscherming van implementatie details (information hiding). (Federated) Identity & Access Management Dit is het delen van authenticatie en autorisatie gegevens over de grenzen van de eigen organisatie heen. Partijen die om bepaalde redenen samenwerken, kunnen zo informatiesystemen onderling integreren. Zij vertouwen hierbij op identiteitsinformatie van de andere partij uit de federatie, informatie die zij zelf niet hebben. Elke organisatie onderhoudt het eigen deel van de database. Hoe ver dit vertrouwen gaat, bepaalt een organisatie zelf door het vastleggen van beleidsregels. Het automatisch uitwisselen van gegevens tussen verschillende systemen gaat via gestandaardiseerde protocollen. Webservices wisselen data uit in een vastgesteld formaat. Als eenmaal een identiteit is vastgesteld, dan is deze geldig voor de gehele federatie. Voor een gebruiker betekent dit bij single sign-on dat deze eenmaal in hoeft te loggen voor alle aangesloten services. Deze methode integreert systemen binnen een federatie en vergroot het bereik voor de gebruikers. Authenticatie door een single sign-on is mogelijk over de eigen organisatiegrenzen heen. Netwerkbeveiliging en standaardisatie van communicatieprocessen zijn een vereiste. Een mogelijk nadeel is het ontbreken van een notificatiemechanisme. Identiteitsgegevens worden niet realtime bijgewerkt vanuit de identity provider als op deze server de eigenschappen van een identiteit veranderen of als de identiteit wordt verwijderd. Het verschil met walled garden is het ontbreken van de enkele identity server[4] architectuur maar een architectuur van verbonden identity servers. Voorbeelden van federations zijn: 1) Microsoft‟s .Net passport en .Net TrustBridge, 2) Liberty Alliance Project: Liberty Architecture. (Profile-Based) Identity & Access Management Dit is een template waarmee eigenschappen van een persoon vastgelegd worden in het kader van usermanagement. De eigenschappen zijn niet noodzakelijk gelijk aan de persoonsgegevens in een bronsysteem, maar hebben betrekking op autorisatiegegevens. Door personen een profieltype toe te kennen kan groepsgewijs geautoriseerd worden. Door een persoon aan een profiel te koppelen, kunnen bepaalde vooraf vastgelegde eigenschappen aan een persoon toegekend worden. In een profiel worden bepaalde algemene eigenschappen

45

vastgelegd[6]. Het gebruik van profielen is ook een bekende techniek om websites te personaliseren. Hier wordt dan wel per persoon specifieke informatie in het profiel vastgelegd. (Role-based) Identity & Access Management Relaties worden gelegd tussen gebruikers en rollen en tussen rollen en rechten op systeemdata en systeemfuncties. Met rol gebaseerde autorisatie kunnen grote groepen personen rechten krijgen door hen aan een rol te koppelen. Vervolgens worden aan die rol rechten toebedeeld. Deze manier van autoriseren is eenvoudiger en sneller dan bijvoorbeeld het vastleggen van rechten per persoon. Het op deze wijze autoriseren van personen is niet altijd toereikend. Een alternatief is het gebruik van rolgebaseerde autorisatie in combinatie met het scheiden van rollen en autorisatie door middel van processen[1].

Imperatief Imperatieve autorisatie is het toekennen van rechten als het systeem in uitvoering is (runtime). Runtime autorisatie heeft het voordeel ten opzichte van declaratieve autorisatie dat op basis van actuele inputdata beslist kan worden of toegang verleend kan worden. Declaratieve autorisatie is op basis van vooraf gedefinieerde rollen en profielen. Impersonation Het werken onder synoniem. Deze vorm van autorisatie op een geïmiteerde user wordt gebruikt door processen waarbij autorisatie op een principal onmogelijk is of vertragend werkt. De origineel geauthenticeerde principal werkt dan onder een algemeen synoniem om systeembronnen aan te spreken.

Indirect Indirecte authenticatie. Hierbij wordt de verificatie overgelaten aan vertrouwde IDM systemen. Integer Data-integriteit. Ontvangen gegevens zijn gelijk als op het moment dat zij verstuurd werden. Intrusion detectie Dit is een methode om ongeautoriseerde toegang tot het systeem of netwerk te detecteren. Onder toegang wordt CIA verstaan: Confidentialiteit, Integriteit, Beschikbaarheid) Vertrouwelijkheid en integriteit zijn besproken. Beschikbaarheid heeft betrekking op het verlies van informatie of het onbereikbaar zijn.

46

Kenmerk Een persoonlijk kenmerk waaraan een identiteit uniek te herkennen is.

Kerberos Kerberos is een netwerk authenticatie protocol waarmee communicatie over een onbeveiligd netwerk als Internet mogelijk is om een identiteit vast te stellen. Zowel de server als de cliënt verifiëren elkaars identiteit. Het maakt gebruik van symmetrische encryptie (dubbele sleutel) en heeft hierbij een vertrouwde derde partij nodig (ook wel een trust genoemd)om te identificeren. Na een succesvolle verificatie kan de cliënt via een sessie sleutel (token) verder geautoriseerd worden. De naam Kerberos stamt uit de Griekse mythologie. Kerberos was een driekoppige hond die de poort va Haides bewaakte.

Klassen Datatypes die doormiddel van overerving uitgebreid kunnen worden met aanvullende eigenschappen. Lightweight Directory Access Protocol LDAP is een netwerkprotocol waarmee beschreven wordt hoe informatie uit een directory service benaderd moet worden. De directories hebben een hiërarchische opbouw, gegroepeerd volgens bepaalde attributen.

47

Life cycle Het bestaan van een identiteit binnen een IDM systeem wordt aangeduid met de term life cycle. Provisioning is het beheerproces van een identiteit. Een life cycle begint met het aanmaken van een identiteit en eindigt met ververwijderen (deprovisioning) van een identiteit. Login Login is het proces van aanmelden bij een systeem. Bekendst voorbeeld is het gebruik van een naam en wachtwoord. Longevity Bijhouden historie over raadplegen van- en veranderingen op identiteitsgegevens. MAC Een uniek nummer dat door de fabrikant aan een netwerkkaart wordt gegeven. Machine Het hardware gedeelte van een computer.

Methoden Methoden zij uitvoerbare stukken code in de vorm van functies. Middel Een programma, systeem, of bestand waaraan toegang verleend kan worden. Netwerk Verbinding van aaneengesloten computersystemen. Netwerkprotocol Een gestandaardiseerde manier van communiceren over een netwerk. NTLM NT Lan Manager is een oud protocol dat enkel nog ingezet wordt als Kerberos niet mogelijk is. Enkele voorbeelden: Als de firewall een beperking heeft op de port die door Kerberos gebruikt wordt. Authenticatie vindt plaats door een server buiten het domein. Als de authenticatie via een server gaat die een andere ADF gebruikt met een legacy NTLM trust. Onderhoud

48

Onderhoud is het deel van een provisioning proces waarmee identiteitsgegevens onderhouden worden. Hierbij wordt onderscheid gemaakt tussen onderhoud binnen het eigen domein en onderhoud gedeeld over verschillende systemen heen waarbij gegevens uitwisseling plaatsvindt via een beveiligd netwerk. Open VPN Open VPN is een vrij toegankelijk netwerkprotocol waarmee een beveiligde verbinding te maken is tussen systemen op basis van een peer to peer netwerk techniek.

Opslag Het al of niet tijdelijk bewaren van gegevens. Paspoort Een elektronisch paspoort is een identificatiebron met beschrijvende eigenschappen. Persistent Langdurige opslag van gegevens die bestaan buiten de tijdspanne van de systemen die gebruik maken van deze gegevens. Persoon Een persoon is een individu die bekend is bij een organisatie onder eigenschappen als naam en adres. Vaak bezitten deze personen een identiteit zodat zij geauthenticeerd en geautoriseerd kunnen worden door een computersysteem. PKI (Public Key Infrastructure) Met PKI kunnen verstuurde berichten voorzien worden van een geëncrypte persoonlijke sleutel. Hierdoor kan nagegaan worden of het bericht dat is ontvangen ook daadwerkelijk van een bepaalde zender afkomstig is. Polisy control Voorgedefinieerde beleidsregels die de toegang tot- en het gebruik van identiteitsinformatie bepalen. Autorisatierichtlijnen geven aan hoe rechten uitgedeeld en aangepast kunnen worden. Privacy richtlijnen geven aan welke identiteitsgegevens beschikbaar gesteld kunnen worden. Principal Een principal is een systeemobject met eigenschappen van een geauthenticeerd persoon of proces.

49

Profiel Een profiel beschrijft de eigenschappen van een identiteit. Door het gebruik van profielen kan groepsgewijs rechten toegekend worden. Dit is ook mogelijk met rollen. Propagatie Het doorgeven van een actie of gegeven. Protocol Een set van regels om een bepaalde functie te kunnen uitvoeren. Provisioning Met provisioning worden verschillende databases gesynchroniseerd op het gebied van identiteitsinformatie vanuit een databron. Identiteiten worden automatisch aangemaakt, verwijder of aangepast. Typische databronnen zijn hierbij personeelssystemen en CRMsystemen. Als een identiteit is gecreëerd en verspreid wordt het geleverd met bijbehorende eigenschappen als credentials, rechten en bepaalde rollen. Onder provisioning wordt hier ook een synchronisatie met identiteitinformatie naar de decentrale databases verstaan. Synchronisatie van identiteitsinformatie over verschillende databronnen wordt dan ook wel het provisioning proces genoemd. Provisioning en deprovisioning zijn essentieel voor identity life cycle management. Publieke sleutel cryptografie Publieke sleutel cryptografie is asymmetrische cryptografie. Wordt verder besproken bij cryptografie. Real time Direct en zonder vertraging. Repository Gegevensopslag. Rol Een gedeelde eigenschap tussen personen binnen een groep. Runtime De tijd date en programma actief is.

50

SAML (Security Assertion Markup Language) SAML is onderdeel van het SAML protocol dat voorziet in een beveiligde uitwisseling van Identiteitsgegevens tussen aaneengesloten systemen. Het is een op XML gebaseerd framework en een open standaard. Referentie monitoring Techniek om de betrouwbaarheid van een identity server te garanderen. Secure Socket layer SSL en Virtual private networks (VPNs) bieden een beveiliging voor login verbindingen tussen browsers en websites. Door de toepassing van encryptie en tunnelen over onbeveiligde netwerken als het Internet.

Security Assertion Markup Language SAML is een federatieve identity protocol die veel gebruikt wordt in federatieve omgevingen. Het biedt een hoge interoperabiliteit door standaardisatie. Het is gebouwd op standaarden als XML, SOAP en XML Signature. SAML is een communicatie protocol tussen verschillende partijen en bepaald zelf niet hoe er binnen de modules zelf geautoriseerd wordt. Volgens [16]: SAML is een generiek framework dat voorziet in basis mechanismen om single sign-on te bereiken in een federatieve omgeving.

Selectieve gegevens uitwisseling Een strikt beperkte data uitwisseling van persoonlijke informatie kan de betekenis van de uitgewisselde informatie tenietdoen. Zo zal de gegevens uitwisseling van een antwoord op de vraag of een persoon tot een bepaalde leeftijdsgroep behoort minder betekenen in deze context dan het opvragen een hele set van NAW gegevens. Voor een netwerkarchitectuur is het toepassen van selectieve toegankelijkheid belangrijk om de kwetsbaarheid van het systeem te verminderen. Self Service Een gedelegeerd onderhoud door bevoegde personen of de houder van een identiteit zelf. Self Service kan veel van de onderhoudsdruk bij een partij wegnemen omdat het onderhouden van de gegevens een persoonlijke taak wordt. Nadeel is dat het moment van onderhoud lastiger te sturen is.

51

Setting Variabele instelling die uitgelezen kan worden door een systeem. Silo Silo is een begrenzing die veel voor komt voor Internetarchitecturen. Het gaat hierbij om een invariant systeem als het gaat om identity and access management. [4] Single sign-on and Access Management Autorisatie kan op bron, rol, profiel, claim of XACML. De methoden rol based, profiel based en claim based worden hierna beschreven. De andere methoden komen bij het aspect beveiliging aan bod. Sigle sign-on betekent zoveel als eenmaal inloggen of eenmaal identificeren. Dit vergroot het gevoel van integratie voor gebruikers omdat zij slecht eenmaal hoeven in te loggen met een naam en wachtwoord of met een certificaat. Na een succesvolle eenmalige inlogprocedure zal de gebruiker verder niet meer om een identificatie worden gevraagd. SmartCard Een kaart voorzien van een microchip.

SPML (Service Provisioning Markup Language) SPML is een standaard voor het provisioning proces over gedistribueerde systemen.

Standaard Wijdverspreid en alom geaccepteerde methode. Symmetrisch Encryptie waarbij een sleutel gebruikt wordt voor het versleutelen als het ontsleutelen. Ticket Een digitaal nummer waar toegangsrechten aan ontleend kunnen worden. Toekennen Het uitdelen van rechten. Tracing Bijhouden van veranderingen op data.

52

Trust Een trust betekent dat systemen elkaar vertrouwen. De drie Trust modellen zijn: 1) Paarsgewijs model, 2) Een bemiddeld model en 3) Gemeenschappelijk model. Uitwisseling Gegevens delen. Uniek Een enkel exemplaar. Authenticatiesleutels zijn bijvoorbeeld uniek voor een identiteit. Een identiteit kan geïdentificeerd worden op basis van een unieke sleutel. Url-autorisatie Beperking op bestanden en directories. Deze vorm van autorisatie wordt gebruikt om te bepalen welke type bestanden (html,asp,aspx, ..) door welke gebruiker of groep benaderd mogen worden. Een bestand wordt door een URL aangevraagd door de cliënt. Als de webapplicatie op de server is geconfigureerd met URL autorisatie zal aan de hand van de principal bepaald worden of het bestand op te vragen is. Valideren Proces om goedkeuring of afkeuring af te geven. Verantwoord Volgens afgesproken richtlijnen. Verbinding Tot standgebrachte communicatie tussen systemen. Verdeeld Buiten een domein om. Over verschillende domeinen heen. Verificatie Nagaan, controleren of gegevens kloppen. Vertrouwelijkheid Gegevens kunnen alleen gebruikt worden door de persoon of systemen waarvoor deze gegevens bedoeld zijn. [5] zegt hierover: ”Data moet worden beschermd tegen ongeautoriseerde toegang. Dit wordt in de meeste gevallen bereikt door encryptie van de gegevens en communicatie verbindingen. Encryptie geeft een extra bescherming voor persistente data waar ook autorisatie toegepast wordt. Communicatie verbindingen, echter, beschikken niet over autorisatie middelen. Encryptie is hierbij de enige bescherming tijdens het versturen van vertrouwelijke informatie over publieke communicatie kanalen.” Voor Internet applicaties is in dit geval communicatie over een https verbinding, over een Secure Socket Layer, aan te bevelen. Virtual Private Network (VPN) is een ander voorbeeld van een methode om een beveiligde verbinding tot stand te brengen. Verwijderen Onderdeel van het deprovisioning proces. Vluchtig Niet blijvend. VPN Virtual Private Network. Een beveiligde verbinding.

53

Vrijgave Toestaan dat bepaalde gegevens worden gebruikt. Wachtwoord authenticatie Hierbij wordt enkel de identiteit van de principal vastgesteld in tegenstelling tot wederzijdse identificatie zoals deze plaats vindt bij netwerk authenticatie protocollen als Kerberos. Bekend voorbeeld is aanloggen door middel van gebruikersnaam en wachtwoord. Het is dan niet mogelijk voor de gebruiker om de identiteit van het systeem vast te stellen en moet erop vertrouwen dat het systeem voldoende beveiligd is. Een correcte gebruikersidentificatie is belangrijk voor verdere autorisatie. Walled garden Een systeem van aaneengesloten organisaties met een enkele identity server. XACML (eXtensible Access Control Markup Language) XACML levert een algemeen mechanisme voor het uitdrukken van beleidsregels voor het uitvoeren van toegangscontrole. Het voorziet in een samenwerking tussen uiteenlopende systemen[Cardea: Dynamic Access Control in Distributed Systems]. XACML is bedoeld om beleidsregels uit te drukken als; voor wie, wat, waneer en hoe wordt er toegang verleent. Zowel functioneel als informatief.[19]

54

Standaard producten

Enkele softwareleveranciers en hun producten op het gebied van systeemintegratie, ID&AM: ActiveIdentity ActiveIdentity is leverancier van producten op het gebeid van authenticatie en remote access security. Het product SecureLogin Single Sign-On levert een verzameling credentials om toegang te verlenen aan heterogene systemen binnen grote gedistribueerde omgevingen. BMC software. BMC software is gericht op het aanbieden van oplossingen voor het OpenNetwork. Zij hebben OpenNetwork overgenomen dat technologieën bevat voor webtoegang beheer en single signon op de volgende vijf gebieden. 1) Directory beheer en visualisatie, 2) Toegang beheer, 3) Wachtwoord beheer, 4) Gebruikersbeheer en Provisioning, 5) naleving en audit controle. Verschillende producten integreren met MIIS zoals Business Proces manager en een aantal derde partij provisioning modules met; SAP, SUN Solaris, Oracle en Linux. Voor een organisatie kan dit interessant zijn als zij gegevens van externe organisaties/klanten automatisch willen koppelen met het eigen systeem door middel van provisioning. Centrify DirectControl Suite 3 breidt Active directory identity, toegang en beleidsservice uit naar UNIX, Linux, Java en webplatformen. Het laat organisaties snel integreren met meerdere identiteiten zonder belangrijke veranderingen in het gebruik van Active Directory of de Linux en Unix infrastructuur. Het voorziet in een eenvoudig gebruik van AD samen met de andere platformen. DigitalPersona Digitalpersona heeft samengewerkt met Microsoft om het gebruik van fingerprint authenticatie mogelijk te maken binnen netwerken, websites en applicatie inlog procedures. Gebruikers worden uniek en ondubbelzinnig geïdentificeerd. M-Tech Information technology M-Tech is een belangrijke leverancier van derde partij oplossingen. Het product M-Tech IDM Suite is een volledig geïntegreerde oplossing voor het enterprise gebruikersbeheer en authenticatie met wachtwoord, tokens, bio-metriek en certificaten. De suite bevat o.a. IDSynch voor user provisioning en P-Synch voor wachtwoord management en ID-Access voor zelfbediening. Het opereert exclusief onder Microsoft 2000 Server en Windows Server 2003. Het voorziet in provisioning, beheer en het deactiveren van login accounts op elk Microsoft product. Het is volledig geïntegreerd met MIIS 2003. Microsoft Microsoft is een belangrijke softwareleverancier en levert op het gebied van systeemintegratie, identity and access management producten als Geneva, MIIS, AD, en.NET Form authenticatie. Het geneva framework biedt de basis voor het microsoft identity beheer systeem Volume Licensing Authentication/Authorisation System (VLAS). Het centraliseert authenticatie en

55

levert een standaard programmeer model voor claim-based autorisatie. Hiermee zijn symptomen als bijvoorbeeld gefragmenteerde inlog procedures van systeem tot systeem, kenmerkend voor deels geïntegreerde systemen, verledentijd. Applicatiecode, nodig voor authenticatie en autorisatie doeleinden kunnen vervangen worden door een standaard claimbased programmamodel wat programma specifieke authenticatie en autorisatie methoden overbodig maken. De methode is bij VLAS verschoven van Role-based Access Control (RBAC) naar claim-based. Het .NET framework met Visual Studio biedt ontwikkelaars een aantal methoden om toe te passen binnen .NET applicaties. Authenticatie: 1) Windows authenticatie en IIS, 2)Paspoort en 3)Form authenticatie. Passlogix Passlogix ontwikkelt software producten die ondersteuning bieden- en faciliteren bij veilig beheer van gebruikersnamen en wachtwoorden. Het product v-GO Single Sign-On kan ingezet worden zonder de moeilijke integratie die SSO oplossingen soms opleveren. Het werk vrijwel elk host: Windows, Web, Java. Het is een universele single sign-on oplossing dat werkt met alle applicaties zonder een lange en complexe implementatie traject. Het is geschikt voor methodes als sterke authenticatie, enterprise brede identity management of methodes voor inloggen. Proginet Leverancier van identity management, provisioning en wachtwoord beheer software oplossingen. De oplossingen voldoen aan de eisen van volledige gebruikers life-cycle beheer zoals geautomatiseerd wachtwoord beheer, zelfbediening wachtwoord reset, geautomatiseerd gebruikers provisioning, gedelegeerde account registratie en audit controle. Quest Quest uitbreidingen op AD zodat UNIX en Linux systeemadministrateurs hun authenticatie kunnen centraliseren om de AD service heen. Het integreert met het beveiligingssystemen gebruikt op Linux en UNIX en voorziet in authenticatiemechanismen binnen services en applicaties op Linux en UNIX. RSA Security RSA Security levert Identity en Access management oplossingen op het gebied van usermanagement, single sign-on, provisioning, web services, sterke authenticatie (certificaten, vingerafdruk), access management en federatieve identiteitsbeheer. Version3 Version3 biedt met Simple Sign-on een robuuste maar simpele gebruikersbeveiliging en productiviteit te verbeteren door te integreren met AD.

manier

om

Gartner Een organisatie die regelmatig rapporten publiceert op het gebied van standaard oplossingen voor identity and access management is Gartner. Zij onderzoeken de markt en plaatsen de leveranciers en hun producten in een helder perspectief voor eventuele afnemers. [8, 9, 10, 11]

56

Referenties [1] Kerberos An Authentication Service for Computer Networks. B. Clifford Neuman and Theodore Ts'o Institute of Electrical and Electronics Engineers http://gost.isi.edu/publications/kerberos-neuman-tso.html [2] Authentication for Distributed Systems Thomas Y.C. Woo Simon S. Lam http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.9374 [3] CSA Cloud Security. Alliance Guidance for identity and Access management 2010 Cloud Security Alliance. [4] Identity Management: setting Context, Joseph Pato http://www.hpl.hp.com/personal/Joe_Pato/ [5] Software Architecture in Practice, Len Bas, Paul Clements, Rick Kazman [6] CSA Domain 12L Guidiance for identity & Access management V2.1 http://www.cloudsecurityalliance.org/guidance/csaguide-dom12.pdf [7] Identity Management in kaart gebracht, Bart de Best http://www.dbmetrics.nl/fileadmin/user_upload/DBmetrics/Artikelen/ArtikelITBM2006 nr2. IdentityManagement in kaart gebracht.pdf [8] Magic Quadrant for User Provisioning, 2H07, Gartner. Earl Perkins, Roberta J. Witty http://www.gartner.com/DisplayDocument?id=514412 [9] Identity and Access Management Defined, Gartner http://www.gartner.com/technology/summits/na/identity-access/ [10] In Our Opinion: Evaluating Identity and Access Management Vendors, Gartner. Roberta Witty, Ray Wagner, Gregg Kreizman http://www.gartner.com/teleconferences/attributes/attr_159904_115.pdf [11] MarketScope for Enterprise Single Sign-On, Gartner Gartner RAS Core Research Note G00170568, Gregg Kreizman, 15 September 2009 http://on2it.net/downloads/IBM_Tivoli_TAMESSO_Gartner_Report.pdf [12] The Laws of identity, Kim Cameron. http://www.identityblog.com/stories/2004/12/09/thelaws.html [13] Proposal for a Common Identity Framework: A User Centric Identity Metasystem.

57

Kim Cameron. Reinhard Posch, Kai Ranneberg http://www.identityblog.com/wpontent/images/2009/06/UserCentricIdentityMetasystem .pdf [14] Active Directory Federation Services: A Path to Federated Identity and Access Management. Microsoft Corporation http://msdn.microsoft.com/en-us/library/ff423674.aspx [15] Microsoft Identity and Access Management Series http://technet.microsoft.com/en-us/library/cc162924.aspx [16] A guide to claim-based identity and access control. Microsoft http://www.microsoft.com/download/en/details.aspx?id=19909 [17] Federated Identity Management Solutions. Jyri Kallela http://www.cse.tkk.fi/en/publications/B/1/papers/Kallela_final.pdf [18] On Adaptive Identity Management: The Next Generation of Identity Management Technologies. Marco Casassa Mont, Pete Bramhall, Joe Pato [19] Using SAML and XACML for Complex Authorisation Scenarios in Dynamic Resource Provisioning. Yuri Demchenko, Leon Gommans, Cees de Laat http://www.uazone.org/demch/papers/ares2007-authz-saml-xacml-07.pdf [20] Identity Analytics - "User Provisioning" Case Study: Using Modelling and Simulation for Policy Decision Support. Marco Casassa Mont, Adrian Baldwin, Simon Shiu http://www.hpl.hp.com/techreports/2009/HPL-2009-57.html [21] Economics of Identity and Access Management: Providing Decision Support for Investments. M. Casassa Mont, Y. Beres, D. Pym, S. Shiu http://www.hpl.hp.com/techreports/2010/HPL-2010-11.pdf [22] ATAM: Method for Architecture Evaluation. Rick Kazman, Mark Klein, Paul Clements http://www.sei.cmu.edu/reports/00tr004.pdf [23] Cardinality-Based Feature Modeling and Constraints: A Progress Report. Krzysztof Czarnecki, Chang Hwan Peter Kim http://softwarefactories.com/workshops/OOPSLA-2005/Papers/Czarnecki.pdf [24] Formalizing Cardinality-based Feature Models and their Specialization. Krzysztof Czarnecki, Simon Helsen, Ulrich Eisenecker http://twiki.cin.ufpe.br/twiki/pub/SPG/WeeklySeminar/spip05a.pdf [25] Explicit Assumptions Enrich Architectural Models. Patricia Lago. Hans van Vliet http://www.cs.vu.nl/~hans/publications/y2005/icse2005/assumptions.pdf [26] Software Deterioration And Maintainability A Model Proposal. Rikard Land http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.20.764 [27] Design erosion: problems and causes. Jilles van Gurp. Jan Bosch

58

http://www.jillesvangurp.com/static/designerosionproblemsandcauses.pdf [28] The Mythical Man-Month - Essays On Software Engineering. Brooks F. P. http://en.wikipedia.org/wiki/The_Mythical_Man-Month http://tal.forum2.org/mythman [29] Moving Towards Quality Attribute Driven Software Architecture Reconstruction. Christoph Stoermer. Liam O‟Brien. Chris Verhoef http://www.cs.vu.nl/~x/square/qadsar.pdf [30] Evaluating Software Architectures: Methods and Case Studies Paul Clements , Rick Kazman , Mark Klein http://www.amazon.com/Evaluating-Software-Architectures-MethodsStudies/dp/020170482X [31] SAAM: A Method for Analyzing the Properties of Software Architectures. Rick Kazman, Len Bass, Gregory Abowd, Mike Webb http://enel.ucalgary.ca/People/far/Lectures/SENG401/PDF/SAAM_details.pdf [32] Documenting Software Architecture. Views and Beyonds. Paul Clements, Felix Bachman, Len Bass, David Garlan, James Ivers, Reed Litle, Paulo Menson, Robert Nord, Judith Staford [33] The 4+1 View Model of Architecture Philippe b. Kruchten http://en.wikipedia.org/wiki/Philippe_Kruchten http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf Paper published in IEEE Software 12 (6) November 1995, pp. 42-50 [34] Supporting Virtual Organization LifecycleManagement by Dynamic Federated User Provisioning Wolfgang Hommel, Michael Schiffers http://www.lrz.de/~hommel/data/papers/ovua2006.pdf [35] A Heterogeneous Network Access Service based on PERMIS and SAML Gabriel Lopez, Oscar Canovas, Antonio F Gomez-Skarmeta, Sassa Otenko, David W Chadwick http://www.mendeley.com/research/a-heterogeneous-network-access-service-based-onpermis-and-saml/ [36] AmTRUE: Authentication Management and Trusted Role-basedAuthorization in Multi-Application and Multi-User Environment S Fugkeaw, P Manpanpanich, S Juntapremjitt http://www.mendeley.com/research/amtrue-authentication-management-trustedrolebased-authorization-multiapplication-multiuser-environment/ [37] Authorization and Certificates: AreWe PushingWhenWe Should Be Pulling? Jason Crampton Hemanth Khambhammettu http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.116.7532 [38] What is Identity and Access Management? Gamatech. [39] Trust Requirements in Identity Management. Audun Jøsang1, John Fabre2, Brian Hay2, James Dalziel3 , Simon Pope1 http://web.mac.com/skjpope/downloads/files/trustidentity.pdf [40] Liberty Alliance: Liberty Trust Models Guidelines John Linn, RSA Laboratories, Sharon Boeyen, Entrust,Gary Ellison, Sun

59

Microsystems,Niina Karhuluoma, Nokia,William MacGregor, Schlumberger,Paul Madsen, Entrust,Senthil Sengodan, Entrust,Serge Shinkar, Communicator, Peter Thompson, IEEEISTO http://projectliberty.org/liberty/content/download/1232/8000/file/liberty-trust-modelsguidelines- v1.0.pdf [41] Establishing and protecting digital identity in federation systems. Abhilasha Bhargav-Spantzel, Anna C. Squicciarini and Elisa Bertino http://asquicciarini.ist.psu.edu/pdf/jcss.pdf [42] Feature-Oriented Domain Analysis (FODA) Feasibility Study. Kyo C. Kang, Sholom G. Cohen,James A. Hess,William E. Novak,A. Spencer Peterson http://www.sei.cmu.edu/reports/90tr021.pdf [43] Identity Management . Trust Negotiation in Identity Management. ABHILASHA BHARGAVSPANTZEL, ANNA C. SQUICCIARINI, AND ELISA BERTINO Purdue University http://asquicciarini.ist.psu.edu/pdf/IEEESP.pdf [44] The Evolution of Identity and Access Management. Deborah Golden http://www.ca.com/files/whitepapers/evolution_of_iam_wp.pdf [45] Oracle Press Release http://www.oracle.com/us/corporate/press/170447 [46] Cams NASA Customer Case Study http://www.cafesoft.com/products/cams/camsCaseStudies/CamsNASACaseStudy.pdf [47] Tools4ever’s Single Sign On http://www.spaceguard.com/company/customers/talant/

60

Afbeeldingen uit begrippenlijst http://penguin.dcs.bbk.ac.uk/academic/networks/data-link-layer/packets/index.php http://technet.microsoft.com/en-us/library/cc700822.aspx http://www.wwbtc.com/stories/securing-your-network-intrusion-detection-software http://www.danieletosatto.com/2010/11/08/load-balancing-ldap-authentication http://en.wikipedia.org/wiki/Identity_management http://www.smartcardsupply.com/Content/Cards/SLE4442.htm http://arun-architect.blogspot.com/2010/12/06-deployment-performance-patterns.html http://code.google.com/intl/nl-NL/googleapps/domain/sso/saml_reference_implementation.html http://library.thinkquest.org/06aug/00446/Censorship.html http://www.myh3r3.com/geek/ssl-encryption-compromised/ http://www.theoi.com/Ther/KuonKerberos.html http://www.ov-chipkaart.me/blog/?p=168 http://www.obs-barg.nl/index.php?page=identiteit http://www.medicalfacts.nl/2010/11/15/sleutelbos-en-id-kaart-straks-vervangen-door/ http://www.thewisdumb.org/blog/2011/02/25/symmetric-vs-asymmetric-encryption/ http://onjava.com/onjava/2003/11/19/exceptions.html http://www.file-recovery-software.co.uk/tag/data-recovery/ http://flylib.com/books/en/2.793.1.20/1/ http://www.maxi-pedia.com/what+is+heap+and+stack http://www8.org/w8-papers/3b-web-doc/runtime/runtime.html http://www.computerworld.com/s/article/86225/SPML

61