Forum Standaardisatie. Expertadvies WS-Policy en XACML standaarden voor authenticatie en autorisatie. Datum 5 augustus 2011

Transcriptie

1 Forum Standaardisatie Expertadvies WS-Policy en XACML standaarden voor authenticatie en autorisatie Datum 5 augustus 2011

2 Colofon Projectnaam Expertadvies WS-Policy en XACML standaarden voor authenticatie en autorisatie Versienummer 1.0 Locatie Organisatie Forum Standaardisatie Postbus JE Den Haag Auteurs drs. J. Kuipers RE RA ir. L.M. Punter Pagina 2 van 29

3 Inhoud Colofon... 2 Inhoud... 3 Managementsamenvatting Doelstelling expertadvies Achtergrond Proces Vervolg Samenstelling expertgroep Toelichting WS-Policy en XACML Toenemend belang van identificatie, authenticatie en autorisatie WS-Policy XACML Relatie met andere open/gangbare standaarden Leeswijzer Algemene verkenning van beide standaarden en het domein Inleiding Externalisering van identity management, authenticatie en autorisatie Afspraken en architectuur Algemene architectuur Architectuur binnen organisaties Architectuur voor samenwerking tussen organisaties WS-Policy XACML SAML Toetsing van standaard aan criteria Openheid Goedkeuring en handhaving Beschikbaarheid Intellectueel eigendom Hergebruik Bruikbaarheid Volwassenheid Functionaliteit Standaarden Potentieel Leveranciersonafhankelijkheid Pagina 3 van 29

4 3.3.2 Interoperabiliteit Impact Bedrijfsvoering Informatievoorziening Technologische risico s Beveiliging en privacy Migratie Advies aan Forum en College Advies ten aanzien van de ingediende standaarden WS-Policy XACML Aanvullende aanbevelingen Pagina 4 van 29

5 Managementsamenvatting Waar gaat het inhoudelijk over? Steeds vaker worden identificatie, authenticatie en autorisatie van gebruikers van ICT-systemen afgehandeld door een centraal systeem. Dit kan een centraal systeem zijn binnen één organisatie of binnen een groep van organisaties. Deze ontwikkeling wordt ook wel externalisering genoemd. Een voorbeeld hiervan is het gebruik van DigiD als centrale inlogmethode op websites van de overheid. WS-Policy en XACML zijn twee standaarden die binnen dit domein een rol kunnen spelen. WS-Policy richt zich op het toepassen van beleidsregels (bijvoorbeeld rondom privacy) bij geautomatiseerde berichtenuitwisseling tussen systemen. XACML is een standaard waarmee regels voor autorisatie vastgelegd en uitgewisseld kunnen worden. Hoe is het proces verlopen? De standaarden zijn aangemeld door Centric. Op basis van de aanmelding is gezocht naar een sponsor binnen de overheid. eherkenning is bereid gevonden op te treden als sponsor. Vervolgens is een expertgroep geformeerd die heeft gekeken naar de aanmelding en op verzoek van het Forum ook in brede zin naar afspraken en standaarden binnen het domein van authenticatie en autorisatie. De expertgroep bestond uit 23 experts uit het bedrijfsleven, wetenschap en de overheid. Wat is de conclusie van de expertgroep? De expertgroep adviseert af te zien van opname van WS-Policy. Deze standaard richt zich op elektronische berichtenuitwisseling op basis van webservices. Daarvoor is reeds een overheidsbreed profiel ontwikkeld in de vorm van Digikoppeling; dit profiel wordt al verplicht via het pas toe of leg uit regime. De waarde van het zelfstandig opnemen van WS-Policy is daardoor beperkt. Het lijkt de expertgroep dan ook verstandig de keuze over het wel of niet toepassen van WS-Policy als verplichte standaard over te laten aan Digikoppeling. XACML wordt door de expertgroep bestempeld als kansrijke standaard voor autorisatie. De ervaring met deze standaard is echter nog beperkt. Daarom wordt geadviseerd de standaard nu nog niet op te nemen op de lijst voor pas toe of leg uit. Pagina 5 van 29

6 Welke additionele adviezen zijn er? De expertgroep onderstreept het belang van samenhang op het gebied van identificatie, authenticatie en autorisatie. Voor een belangrijk deel zijn er eerst nog onderzoeks- en ontwikkelvraagstukken die opgelost moeten worden, voordat gekeken kan worden naar standaardisatie van het geheel. De ervaring met externalisering van autorisaties is nog beperkt, het belang van dit onderwerp neemt toe, XACML is een kansrijke standaard 1. Start met een aantal overheidsorganisaties en marktpartijen pilot trajecten om meer ervaring op te doen bij het gebruik van XACML in de praktijk, deel de resultaten. 2. Onderzoek via deze pilot trajecten in hoeverre het noodzakelijk is om behalve XACML ook specifieke attributen te standaardiseren. Mogelijk is de conclusie dat het noodzakelijk is een profiel te ontwikkelen voor de Nederlandse overheid. 3. Onderzoek via deze pilottrajecten of XACML voorgeschreven moet worden als definitietaal voor autorisatieregels of als protocol voor de uitwisseling daarvan, of voor beide. 4. Onderzoek of versie 2.0 (huidige versie) of juist versie 3.0 (verwachte versie) in aanmerking zou moeten komen voor de lijst voor pas toe of leg uit. Er is een relatie tussen identificatie, authenticatie en autorisatie en de daarin gebruikte standaarden, in het bijzonder SAML (voor authenticatie) en XACML (voor autorisatie). 5. Onderzoek of het toepassingsgebied van SAML op de lijst voor pas toe of leg uit verbreed moet worden ten opzichte van de huidige formulering. Bij dit onderzoek zou nadrukkelijk het beschikbare SAML-profiel van XACML betrokken moeten worden. Er is samenhang gewenst 6. Ga op basis van de ervaringen van overheidsorganisaties na of er noodzaak bestaat tot het voorschrijven van standaarden voor identificatie, authenticatie en autorisatie binnen organisaties. De verwachting is dat een infrastructuur voor identificatie, authenticatie en autorisatie binnen een organisatie in toenemende mate ook geschikt moet zijn om met andere organisaties samen te werken. 7. Ontwikkel een referentiearchitectuur voor identificatie, authenticatie en autorisatie binnen de overheid. Pagina 6 van 29

7 1 Doelstelling expertadvies 1.1 Achtergrond In 2007 is door het kabinet besloten tot een actieplan open standaarden en open source software 1. Het doel van dit actieplan is om de informatievoorziening toegankelijker te maken, onafhankelijkheid van ICT-leveranciers te creëren en de weg vrij te maken voor innovatie. Eén van de maatregelen van het actieplan is het gebruik van een lijst met standaarden, die vallen onder het principe "pas toe of leg uit" (comply-orexplain). Het College Standaardisatie spreekt zich uit over de standaarden die op de lijst zullen worden opgenomen, o.a. op basis van een expertbeoordeling van de standaard. Onderwerp van dit expertadvies zijn de standaarden WS-Policy en XACML. Dit zijn standaarden binnen het domein van identificatie, authenticatie en autorisatie. De beide standaarden zijn aangemeld door Centric voor opname op de lijst met open standaarden voor pas toe of leg uit ; deze aanmelding is ondersteund door het programma eherkenning. De opdracht aan de expertgroep was om: een advies op te stellen over het wel of niet opnemen van deze standaard op de lijst met open standaarden, al dan niet onder bepaalde voorwaarden. een uitspraak te doen over de context waarin deze standaarden ingezet zouden moeten worden: o de rol in het toepassingsdomein o welke eventuele andere standaarden een rol spelen; en o de maatregelen die genomen moeten worden voor een succesvolle inzet. Door het Bureau Forum Standaardisatie zijn 23 experts verzameld in een expertgroep om dit advies uit te brengen. 1.2 Proces Voor het opstellen van dit advies is de volgende procedure doorlopen: - Door het Bureau Forum Standaardisatie is een intakegesprek gevoerd met de initiële indiener (Centric). Hierin is de standaard getoetst op uitsluitingscriteria ( criteria voor in behandel-name ) en is een eerste inschatting gemaakt van de kansrijkheid voor opname. - Na de intake is op verzoek van het Bureau Forum Standaardisatie eherkenning aangezocht als sponsor vanuit de overheid voor de aanmelding. eherkenning heeft hiermee ingestemd. - Besloten is tot het instellen van de expertgroep, met het mandaat om zich in de breedte uit te spreken over de materie (zoals beschreven in de vorige paragraaf). 1 Actieplan Nederland Open in Verbinding, 's-gravenhage: Ministerie van Economische Zaken, Pagina 7 van 29

8 - Als voorzitter is aangezocht Jaap Kuipers. Hij heeft een brede betrokkenheid bij het onderwerp, zonder dat hij een specifieke belanghebbende is. - Vervolgens is de expertgroep op 20 juli bijeengekomen. In deze bijeenkomst is een verkenning gedaan van de beide ingediende standaarden en het domein. Op basis hiervan is de expertgroep tot conclusies gekomen. De bevindingen van de expertgroep zijn door de voorzitter en begeleider verwerkt in dit rapport. Een eerste conceptversie is aan de leden van de expertgroep gestuurd met verzoek om reactie. Na verwerking van de reacties is het rapport afgerond en ingediend voor de publieke consultatieronde. 1.3 Vervolg Dit expertadvies zal ten behoeve van een publieke consultatie openbaar worden gemaakt door het Bureau Forum Standaardisatie. Alle belanghebbenden kunnen gedurende de consultatieperiode op dit expertadvies hun reactie geven. Het Bureau Forum Standaardisatie legt vervolgens de reacties voor aan de voorzitter en indien nodig aan de expertgroep. Het Forum Standaardisatie zal op basis van het expertadvies en relevante inzichten uit de openbare consultatie een advies aan het College Standaardisatie opstellen. Het College Standaardisatie bepaalt uiteindelijk op basis van het advies van het Forum of de standaard op de lijst met gangbare open standaarden of de 'pas toe of leg uit'-lijst komt. 1.4 Samenstelling expertgroep Voor de expertgroep zijn personen uitgenodigd die vanuit hun persoonlijke expertise of werkzaamheden bij een bepaalde organisatie direct of indirect betrokken zijn bij de standaard. Daarnaast is een onafhankelijke voorzitter aangesteld om de expertgroep te leiden en als verantwoordelijke op te treden voor het uiteindelijke expertadvies. Als voorzitter is opgetreden Jaap Kuipers. Hij is oprichter van het Platform Identity Management Nederland en betrokken bij ECP-EPN.nl. In het verleden was hij o.a. adviseur bij DigiNotar en SURFnet, op het gebied van identity management. De expertgroep is in opdracht van het Forum Standaardisatie begeleid door ir. Matthijs Punter, adviseur standaarden en interoperabiliteit bij TNO. Aan de expertgroep hebben deelgenomen: Mike Dell, adviseur identity management,ictu Bart Ratgers, consultant, QNH Remco Poortinga-van Wijnen, adviseur middleware services, SURF Raymond Roelands, IT Manager, Connectis / Federate Now Rémon Sinnema, Consultant Software Engineer bij EMC, tevens lid van de OASIS technical committee voor XACML Barry Dukker, adviseur, IVENT Rob van der Staaij, adviseur identity management, Atos Albert Kapper, JustID Pagina 8 van 29

9 Erik Holkers, Ministerie van EL&I, Dienst ICT en Uitvoering Henk Romeijn, Ministerie van EL&I, Dienst ICT en Uitvoering Tom Peelen, architect, Logius Kees De Jong, architect DigiD Machtigen en GOA, Logius Gé Iking, senior adviseur, Centric, tevens indiener Koen Laan, software architect, Centric Willem de Pater, consultant, Oracle Willem Kosse, architect, BKWI, lid architectuurraad Manifestgroep Harry Biersteker, adviseur informatiemanagement, Ministerie van Justitie Lex Borger, identity & access management, Domus Technica Rob Weemhoff, senior managing consultant Security & Privacy, IBM Jeroen de Beer, Anoigo Maarten Wegdam, onderzoeker, Novay Carl Adamse, senior IT adviseur, Ministerie van Binnenlandse Zaken & Koninkrijksrelaties Michaël Stoelinga, adviseur, eherkenning De experts zijn voorafgaand aan de sessie gevraagd input aan te leveren. Deze input is gebruikt bij het structureren van de discussie. Specifiek is aan de experts gevraagd de beide standaarden te scoren op basis van de door het Forum en College Standaardisatie gehanteerde criteria 2 voor opname op de lijst voor pas toe of leg uit. Voorafgaand aan de sessie heeft Pim van der Eijk (werkzaam voor OASIS) een aanvullende inhoudelijke bijdrage geleverd. Deze bijdrage is meegenomen in de discussie in de expertgroep. 1.5 Toelichting WS-Policy en XACML Toenemend belang van identificatie, authenticatie en autorisatie WS-Policy en XACML zijn standaarden binnen het domein van identificatie, authenticatie en autorisatie. In toenemende mate worden deze functies losgekoppeld van individuele systemen en applicaties. Een voorbeeld is het inrichten van een directory met medewerkers, op basis waarvan de inlog in computersystemen kan plaatsvinden. Deze loskoppeling zal naar verwachting in de toekomst steeds verder gaan: Daar waar ze nu nog vaak gecombineerd zijn worden systematieken voor identificatie, authenticatie en autorisatie worden steeds vaker losgekoppeld van elkaar. Binnen organisaties worden bedrijfsbrede systematieken voor identificatie, authenticatie en autorisatie ingericht, waar zo veel mogelijk applicaties op moeten aansluiten. Er zijn ontwikkelingen op komst waarbij identificatie, authenticatie en autorisatie over meerdere organisaties gedeeld worden. Een voorbeeld is het gebruik van DigiD als identificatie en authenticatie toepassing voor webapplicaties van de overheid voor burgers. Een ander voorbeeld is het samenwerken van meerdere 2 Pagina 9 van 29

10 overheidsorganisaties in één dossiersysteem, waarbij één inlog is vereist. De beide standaarden WS-Policy en XACML passen volgens de indiener binnen deze ontwikkeling WS-Policy De standaard WS-Policy (formeel Web Services Policy 1.5 Framework ) is een standaard uit de zogenaamde stack van webservice standaarden. Deze standaarden worden gebruikt voor het inrichten van berichtuitwisseling tussen organisaties. WS-Policy is een z.g.n. aanbeveling van W3C (de ontwikkelaar en beheerder) om bij webservices een domeinspecifieke capability, vereisten of karakteristieken toe te voegen. Door dit te doen kunnen webservices tonen in hoeverre wordt voldaan aan bepaald beleid, bepaalde richtlijnen of toegangsvereisten. Denk bijvoorbeeld aan deze webservice implementeert bepaalde privacy-voorschriften of de gegevens van deze webservice vereisen een veiligheidstoets door een externe partij. WS- Policy is op dit punt een zeer generieke standaard. Het beschrijft wel de envelop waarin de policy wordt uitgewisseld, maar niet de vorm of inhoud van deze policy. WS-Policy is een toevoeging op andere standaarden die een webservice beschrijven. In onderstaande figuur wordt WS-Policy gepositioneerd ten opzichte van andere WS-* standaarden: Figuur: positionering WS-Policy Zoals aangegeven is de standaard erg generiek. Naast WS-Policy is het altijd nodig om een formaat te kiezen voor het beschrijven van de gewenste policy. Ten behoeve van autorisatie van gebruikers is XACML daar een mogelijke standaard voor. De standaard is te vinden op Pagina 10 van 29

11 1.5.3 XACML Daar waar WS-Policy zich richt op webservices, is de toepassing van XACML breder; XACML kan op zichzelf worden gebruikt of in combinatie met andere standaarden (zoals WS-Policy, maar ook SAML; zie de volgende paragraaf). XACML is een afkorting voor extensible Access Control Markup Language. Ingediend is versie 2.0. XACML maakt het mogelijk om tot op een zeer diep detailniveau de autorisatie van gebruikers en systemen te definiëren en af te dwingen. De standaard omvat: Een XML- taal om autorisatieregels in vast te leggen Een protocol om deze autorisatieregels uit te wisselen en om te komen tot een daadwerkelijke autorisatie van een gebruiker. Impliciet definieert XACML hiermee ook een architectuur om de autorisatie van gebruikers en systemen buiten een applicatie of zelfs buiten een organisatie te plaatsen. Verderop in dit expertadvies zal daar nader op ingegaan worden. In technische termen wordt XACML ook wel omschreven als een standaard voor attribute based access control (ABAC), waarin toegang wordt gebaseerd op basis van meerdere attributen. Dit gaat verder dan de huidige acces contol lists (ACK) en role based access control (RBAC), dat slechts ingaat op de rol van een gebruiker en op basis daarvan toegang verleent. XACML definieert de attribuutcategorieën subject, action, resource en environment voor het verlenen van toegang. Hiermee is het mogelijk tot op een zeer diep detailniveau te definiëren wie wanneer en onder welke condities waartoe toegang heeft. Onderstaande figuur geeft een indruk van de mogelijkheden. De figuur beschrijft een klant van een bank die geld wil overmaken: Figuur: detailniveau XACML (bron: Anoigo) Of de klant geld mag overmaken hangt af van een samenhang tussen klanttype, leeftijd, klantnummer, vestiging, saldo, tijdstip en locatie. In XACML kan dit uitgedrukt worden. XACML wordt beheerd door OASIS. De standaard is te vinden op Pagina 11 van 29

12 1.6 Relatie met andere open/gangbare standaarden De standaarden hebben relatie met een aantal andere standaarden. De belangrijkste zijn: Digikoppeling Binnen Digikoppeling zijn twee profielen gedefinieerd. In één van deze profielen (WUS) wordt gespecificeerd op welke manier overheden webservicestandaarden moeten inzetten voor het inrichten van berichtuitwisseling. WS-Policy is aanvullend op c.q. samenhangend met de standaarden die in Digikoppeling zijn beschreven. Digikoppeling is opgenomen op de lijst voor pas toe of leg uit met als toepassingsgebied: o OSB-ebMS standaard voor meldingen tussen informatiesystemen o OSB-WUS standaard voor de (geautomatiseerde) bevraging van informatiesystemen Als organisatorisch werkingsgebied is gedefinieerd: Voor sectoroverstijgend berichtenverkeer binnen de publieke sector te hanteren, inclusief het verkeer met de basisregistraties. SAML De standaard SAML (Security Assertion Markup Language) is een standard voor het uitwisselen van authenticatie en autorisatie data tussen systemen. Op dit moment is SAML opgenomen op de lijst voor pas toe of leg uit met als toepassingsgebied: Federatieve (web)browser-based single-sign-on (SSO) en single-sign-off. Dat wil zeggen dat een gebruiker na eenmalig inloggen via zijn browser toegang krijgt tot verschillende diensten van verschillende partijen. De toepassingsmogelijkheid van SAML is echter breder: ook voor andere vormen van uitwisseling van (met name) authenticatiedata kan SAML worden gebruikt. Er is ook een (beperkte) mogelijkheid om SAML in te zetten voor autorisatie. Naast het zelfstandig inzetten van SAML, zijn er scenario s denkbaar waarbij SAML in combinatie met XACML wordt gebruikt, om te profiteren van de fijnmazigheid van de laatste. Beide relaties zijn betrokken in de bespreking van de expertgroep. In het vervolg van dit expertadvies zal nader worden ingegaan op de impact van deze relaties op de eventuele opname van WS-Policy en XACML. Pagina 12 van 29

13 1.7 Leeswijzer Door de expertgroep is een algemene verkenning gedaan van de beide standaarden en het domein. Op basis hiervan is de expertgroep tot conclusies gekomen. Deze algemene verkenning is opgenomen in hoofdstuk 2. In hoofdstuk 3 is een weergave opgenomen van de belangrijkste op- en aanmerkingen die door de experts zijn gegeven tijdens de voorbereiding van de expertgroepbijeenkomst ten aanzien van de toetsingscriteria voor de lijst voor pas toe of leg uit. Tenslotte wordt in hoofdstuk 4 het advies geformuleerd van de expertgroep. Pagina 13 van 29

14 2 Algemene verkenning van beide standaarden en het domein 2.1 Inleiding De vraag van het Forum Standaardisatie aan de expertgroep was breder dan gebruikelijk. Niet alleen is gevraagd om de standaarden te beoordelen op de gestelde criteria, er is ook gevraagd te kijken naar de bredere context van identificatie (het identificeren van een gebruiker), authenticatie (het controleren van de identiteit) en autorisatie (het verlenen van toegang). Dit, vanuit de overtuiging dat hier meerdere standaarden een rol spelen en de vraagstukken mogelijk ook breder liggen dan de keuze voor een standaard. De expertgroep brengt advies uit vanuit dit brede perspectief, maar wel met de beide standaarden als vertrekpunt. 2.2 Externalisering van identity management, authenticatie en autorisatie De aanmelding van de indiener (Centric) voor beide standaarden komt voort uit de constatering dat veel van hun klanten (dikwijls: overheidsorganisaties) steeds vaker gaan werken met geïntegreerde front-, mid-, backoffice-architecturen en deze onderbrengen in shared service centra. Hoewel deze verschillende vormen kunnen hebben, is het duidelijk een afwijking van het tot voor kort gangbare beeld van verticale monolieten, die per functie en per organisatie gescheiden zijn. Centric acht het daarom wenselijk dat de functies van identity management, authenticatie en autorisatie uit de applicaties worden gehaald en worden uitgevoerd door een centrale faciliteit. Vanuit deze faciliteit kan dan (eenvoudig gesteld) geregeld worden wie waartoe toegang heeft. Figuur: Huidige situatie iedere applicatie regelt authenticatie en autorisatie zelf (bron: Centric). Pagina 14 van 29

15 Figuur: Gewenst beeld authenticatie en autorisatie over meerdere applicaties (bron: Centric). Hoewel deze ontwikkeling binnen organisaties kan plaatsvinden, kan deze ook tussen organisaties plaatsvinden. In dat geval gaat het om centrale of gefedereerde modellen, zoals deze o.a. vanuit eherkenning worden ontwikkeld. Een externe entiteit (losstaand van de eigen organisatie) verzorgt in dit geval identificatie, authenticatie en/of autorisatie. Ook zou een externe entiteit regels of vereisten kunnen opstellen op basis waarvan toegang kan worden verleend. Dit buiten de applicatie plaatsen van identificatie, authenticatie en autorisatie kan ook externalisering worden genoemd. Dit kan plaatsvinden binnen de context van één organisatie, maar ook binnen de context van een netwerk van meerdere organisaties ( tussen organisaties ). Binnen organisaties: Externalisering van identiteiten binnen organisaties is langzamerhand gemeengoed aan het worden. Veel organisaties hebben al een directory aangelegd met hierin alle gebruikersaccounts, waarop alle toepassingen binnen de organisatie moeten worden aangesloten. Authenticatie wordt hier in toenemende mate aan gekoppeld. Externalisering van autorisatie binnen organisaties staat nog in de kinderschoenen, maar wordt wel belangrijker (koppelen van applicaties, gedeelde datacentra, etc. - zoals geschetst in paragraaf 1.5.1). Pagina 15 van 29

16 Tussen organisaties: DigiD en eherkenning zijn goede voorbeelden van externalisering van identificatie en authenticatie tussen organisaties. Externalisering van autorisatie tussen organisaties staat nog in de kinderschoenen. Ontwikkelingen als de hervorming van de rijksdienst (samenvoegingen, inrichten shared services, etc.), ketensamenwerking en elektronische dienstverlening maken ketenbrede autorisatiemogelijkheden wel steeds wenselijker. Barrières die voor externalisering tussen organisaties die in de expertgroep zijn genoemd zijn o.a. gebrek aan afspraken en ervaring ( hoe doen we dit? ) en ten aanzien van toepassing tussen organisaties gebrek aan vertrouwen ( iemand anders bepaalt de toegang ). Samengevat: externalisering is een belangrijke trend, vooral ten aanzien van externalisering van autorisaties zijn er nog stappen te zetten. 2.3 Afspraken en architectuur Welke afspraken en architecturen zijn nu nodig/mogelijk om de in de vorige paragraaf geschetste ontwikkeling mogelijk te maken? Algemene architectuur Binnen de overheid zijn op dit moment meerdere architecturen in gebruik op basis waarvan identificatie, authenticatie en autorisatie mogelijk worden gemaakt. Een eenduidig referentiemodel voor identificatie, authenticatie en autorisatie is nog niet opgesteld. Hoewel via het project GOA door een aantal betrokken partijen hieraan wordt gewerkt, mag niet worden verwacht dat dit op korte termijn al leidt tot een algemeen geaccepteerde architectuur. Met name ook omdat GOA een beperkte scope (problematiek Belastingdienst) en een tijdelijk mandaat (tot juli 2011) heeft. Pagina 16 van 29

17 In de expertgroep is door een van de deelnemers onderstaande figuur aangedragen, gebaseerd op ISO/IEC Hoewel afwijkingen mogelijk zijn, en de architectuur op punten uitgediept moet worden, bleek het in de expertgroep een goed vertrekpunt voor de discussie. Figuur: mogelijke referentiearchitectuur identificatie, authenticatie en autorisatie. Deze architectuur kan als volgt gelezen worden: Een client (gebruiker of systeem) zoekt toegang tot een resource. Bijvoorbeeld een ander systeem of een document. De toegang tot de resource wordt verleend via een resource manager. Via identity provider wordt een identiteitsmiddel verstrekt, een authentication engine controleert dit middel. Hiermee is de identiteit van de client vastgesteld. Aan de hand van de identiteit en vastgelegde policies wordt door de authorization engine vastgesteld of de client toegang kan krijgen tot de resource. De standaard SAML concentreert zich in deze architectuur vooral op authenticatie, XACML op autorisatie. Op de rol van beide standaarden wordt in paragraaf 2.5 en 2.6 nader ingegaan. WS-Policy speelt een ondergeschikte rol; deze rol zal in paragraaf 2.4 nader worden toegelicht Architectuur binnen organisaties Het mag duidelijk zijn dat er verschillen zijn tussen de invulling van deze architectuur binnen organisaties en tussen organisaties. Dit vloeit voort uit het gegeven dat het binnen organisaties doorgaans veel eenvoudiger is om afspraken te maken over bijvoorbeeld identiteitsmiddelen of toegangsregels. Pagina 17 van 29

18 De architectuur uit de vorige subparagraaf is dan ook in meer of mindere mate ingevuld binnen grotere organisaties. Verschijningsvormen zijn bijvoorbeeld: Het inrichten van omgevingen voor single-sign-on Het inrichten van een directory met gebruikers Centraal beheer van policies etc. Een belangrijk risico is dat bij de invulling afhankelijkheid ontstaat van één leverancier. Een voorbeeld van de afwegingen op dit punt is te vinden in de realisatielijn Open DWR (Digitale Werkplek Rijk, zie: nopendwrv1.0-1.pdf). Conclusie van de expertgroep t.a.v. de architectuur binnen organisaties: Bij de inrichting van identificatie, authenticatie en autorisatie binnen organisaties zijn meerdere keuzes mogelijk, maar de afhankelijkheid van één leverancier moet worden voorkomen. De expertgroep doet op dit moment geen uitspraken over de exacte open standaarden die toegepast zouden moeten worden voor autorisatie binnen organisaties. In het vervolg van dit expertadvies zal met name gekeken worden naar de situatie tussen organisaties, aangezien dit ook de focus is van de lijst voor pas toe of leg uit Architectuur voor samenwerking tussen organisaties De architectuur tussen organisaties is complexer, vanwege: de inherente extra organisatorische dimensie. de daardoor benodigde extra afspraken over de veiligheid en betrouwbaarheid van de uitwisseling Toch vinden er, zoals in paragraaf 2.2 betoogd, ontwikkelingen plaats, die een architectuur tussen organisaties noodzakelijk maken (shared services, ketensamenwerking, etc.). Deze ontwikkelingen maken het wenselijk om op termijn te komen tot een generieke architectuur, bestaande uit een referentiemodel, bijbehorende afspraken, generieke voorzieningen en specifieke implementaties in deelsectoren. Op dit moment is dit nog een architectuurvraagstuk en geen standaardisatievraagstuk, of anders gesteld: het vergt nog onderzoek en ontwikkeling om te komen tot een raamwerk van afspraken voor een dergelijke architectuur. Pas als dit raamwerk er is kan sprake zijn van een standaardisatietraject (bijvoorbeeld van één of meerdere standaarden of de architectuur als geheel). Conclusie van de expertgroep: Het is wenselijk te komen tot een generieke architectuur voor externalisering van identificatie, authenticatie en autorisatie tussen organisaties; deze architectuur is nog niet bepaald. Deze generieke architectuur zou via een ontwikkeltraject opgesteld moeten worden. Pagina 18 van 29

19 2.4 WS-Policy De relatie tussen WS-Policy en XACML is volgens de expertgroep zwak. Hoewel beide standaarden in combinatie zijn toe te passen, worden beide standaarden in de praktijk vaker los van elkaar (of in combinatie met andere standaarden) gebruikt dan gezamenlijk. Ten aanzien van WS-Policy constateert de expertgroep dat toepassing in combinatie met andere webservicestandaarden het vertrekpunt moet zijn. Verder wordt door de deelnemers van de expertgroep opgemerkt dat er internationaal discussie is over de manier waarop WS-Policy toegepast zou moeten worden en dat binnen Nederland de bekendheid zeer beperkt is. Er zijn geen verdere argumenten aangevoerd die pleiten voor het alsnog apart opnemen van WS-Policy. Hoewel dit niet afdoet aan de mogelijkheden die de standaard biedt, pleit de expertgroep er voor om de discussie over het wel of niet gebruiken van WS-Policy te plaatsen binnen de context van Digikoppeling. Digikoppeling omvat immers een profiel waarin beschreven wordt hoe de verschillende webservicestandaarden ingezet kunnen worden en WS-Policy is een webservicestandaard. De vertegenwoordiger namens Digikoppeling in de expertgroep geeft aan dat de deze discussie nog niet is opgebracht binnen hun beheerproces, wat zou kunnen wijzen op een beperkt potentieel. Conclusie van de expertgroep: De standaard is primair gericht op uitwisseling op basis van webservices, terwijl er ook andere terreinen zijn waarbinnen identificatie, authenticatie en autorisatie moet worden ingericht. Het afzonderlijk afdwingen van WS-Policy via het regime van pas toe of leg uit voert te ver. Via de beheerprocedure van Digikoppeling zou verkend kunnen worden of toepassing van WS-Policy binnen het Digikoppeling WUS-profiel zinvol is. In het vervolg van dit expertadvies zal WS-Policy dan ook verder buiten beschouwing worden gelaten. 2.5 XACML Ten aanzien van XACML maakt de expertgroep een andere afweging. In de in paragraaf gepresenteerde architectuur wordt XACML genoemd als standaard voor autorisatie. XACML kan een belangrijke bijdrage leveren aan interoperabiliteit op dat gebied: Het biedt een codering op basis waarvan attribuut gebaseerd toegangsbeheer mogelijk wordt. Het biedt een protocol op basis waarvan autorisatie ingevuld kan worden. Het definieert impliciet (in lijn met het geschetste model) een architectuur voor autorisatie (samenhang codering en protocol). Tegelijkertijd is de standaard zeer flexibel in te zetten, ook in combinatie met andere standaarden (zoals SAML, zie volgende paragraaf). De expertgroep ziet XACML dan ook als een kansrijke standaard, die eventueel via een pas toe of leg uit mechanisme afgedwongen kan worden. De standaard wordt ook door de markt erkend als belangrijk. Pagina 19 van 29

20 Voor een goede toepassing is echter meer nodig dan enkel een keuze voor een standaard: Het is onduidelijk voor welk toepassingsdomein XACML als standaard verplicht moet worden: als coderingstaal, als protocol of beide. De architectuur (voor identificatie, authenticatie en autorisatie) waarbinnen de standaard ingezet moet worden is nog onvoldoende uitgekristalliseerd (zie paragraaf 2.3) Bij het toepassen van de standaard moeten diverse keuzes worden gemaakt. Op overheidsniveau kan dit bijvoorbeeld betekenen dat er bepaalde attributen voor autorisaties gestandaardiseerd moeten worden in de vorm van profielen. Op dit moment is er onvoldoende praktijkervaring om een eenduidig antwoord hier op te geven. Daarnaast is er ook een aantal overwegingen ten aanzien van de standaard zelf: Op korte termijn wordt versie 3.0 verwacht van de standaard. Het is dan de vraag of op de huidige versie (2.0) gestandaardiseerd moet worden of op dat op de nieuwe versie gewacht moet worden. Er is nog onduidelijkheid ten aanzien van patentkwesties (zie volgende hoofdstuk). Hoewel hier door de expertgroep niet uitgebreid naar gekeken is en het waarschijnlijk niet een doorslaggevend punt zal zijn, is meer helderheid gewenst. Dit maakt dat verplichting via pas toe of leg uit nu nog te vroeg komt. Conclusie van de expertgroep: XACML is een belangrijke doelstandaard binnen het domein van authenticatie en autorisatie. XACML richt zich vooral op het vraagstuk van autorisatie. Hoewel XACML breed ondersteund wordt in de markt, is het gebruik op dit moment nog beperkt. Via pilots en proeven zou meer ervaring opgedaan moeten worden met het gebruik van de standaard. XACML is een brede standaard: o XACML is niet alleen een definitietaal, maar omvat het ook een protocol voor uitwisseling. Het is niet op voorhand duidelijk of XACML alleen verplicht moet worden als taal, als protocol of als beide. o Bij gebruik tussen organisaties moet naast overeenstemming over het gebruik van XACML als standaard ook overeenstemming zijn over de invulling van de diverse attributen. Onderzocht moet worden in hoeverre een specifiek overheidsprofiel op basis van XACML nodig is. De standaard is nu nog niet rijp genoeg voor de lijst voor pas toe of leg uit. Pagina 20 van 29