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

Forum Standaardisatie

Expertadvies WS-Policy en XACML standaarden voor authenticatie en autorisatie

Datum

5 augustus 2011

Expertadvies WS-Policy en XACML | Forum Standaardisatie | 5 augustus 2011

Colofon

Projectnaam Versienummer Locatie Organisatie

Auteurs

Expertadvies WS-Policy en XACML standaarden voor authenticatie en autorisatie 1.0 Forum Standaardisatie Postbus 96810 2509 JE Den Haag [email protected]

drs. J. Kuipers RE RA ir. L.M. Punter

Pagina 2 van 29


Inhoud

Colofon ............................................................................... 2 Inhoud ................................................................................ 3 Managementsamenvatting.................................................. 5 1

Doelstelling expertadvies .............................................. 7 1.1

Achtergrond ............................................................... 7

1.2

Proces ....................................................................... 7

1.3

Vervolg ..................................................................... 8

1.4

Samenstelling expertgroep ........................................... 8

1.5 Toelichting WS-Policy en XACML.................................... 9 1.5.1 Toenemend belang van identificatie, authenticatie en autorisatie ...................................................................... 9 1.5.2 WS-Policy ............................................................ 10 1.5.3 XACML ................................................................ 11 1.6

Relatie met andere open/gangbare standaarden ............. 12

1.7

Leeswijzer ................................................................ 13

2 Algemene verkenning van beide standaarden en het domein ............................................................................. 14 2.1

Inleiding ................................................................... 14

2.2 Externalisering van identity management, authenticatie en autorisatie ........................................................................ 14 2.3 Afspraken en architectuur ........................................... 16 2.3.1 Algemene architectuur ........................................... 16 2.3.2 Architectuur binnen organisaties ............................. 17 2.3.3 Architectuur voor samenwerking tussen organisaties .. 18

3

2.4

WS-Policy ................................................................. 19

2.5

XACML ..................................................................... 19

2.6

SAML ....................................................................... 21

Toetsing van standaard aan criteria............................. 22 3.1 Openheid .................................................................. 22 3.1.1 Goedkeuring en handhaving ................................... 22 3.1.2 Beschikbaarheid ................................................... 22 3.1.3 Intellectueel eigendom........................................... 23 3.1.4 Hergebruik ........................................................... 23 3.2 Bruikbaarheid ............................................................ 23 3.2.1 Volwassenheid ...................................................... 23 3.2.2 Functionaliteit....................................................... 24 3.2.3 Standaarden ........................................................ 24 3.3 Potentieel ................................................................. 25 3.3.1 Leveranciersonafhankelijkheid ................................ 25 Pagina 3 van 29


3.3.2 Interoperabiliteit ................................................... 25 3.4 Impact ..................................................................... 25 3.4.1 Bedrijfsvoering ..................................................... 25 3.4.2 Informatievoorziening ............................................ 25 3.4.3 Technologische risico‟s ........................................... 26 3.4.4 Beveiliging en privacy ............................................ 26 3.4.5 Migratie ............................................................... 26 4

Advies aan Forum en College ....................................... 27 4.1 Advies ten aanzien van de ingediende standaarden ......... 27 4.1.1 WS-Policy ............................................................ 27 4.1.2 XACML ................................................................ 27 4.2

Aanvullende aanbevelingen ......................................... 28

Pagina 4 van 29


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


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


1

Doelstelling expertadvies

1.1

Achtergrond In 2007 is door het kabinet besloten tot een actieplan open standaarden en open source software1. 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, 2007. Pagina 7 van 29


-

-

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


              

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

1.5.1

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 http://www.forumstandaardisatie.nl/fileadmin/os/images/Toetsingsprocedure_en_criteria_v1_0.pdf Pagina 9 van 29


overheidsorganisaties in één dossiersysteem, waarbij één inlog is vereist. De beide standaarden WS-Policy en XACML passen volgens de indiener binnen deze ontwikkeling. 1.5.2

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‟. WSPolicy 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 http://www.w3.org/TR/ws-policy/.

Pagina 10 van 29


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 http://www.oasis-open.org/standards#xacmlv2.0.

Pagina 11 van 29


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


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 open 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


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


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


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?

2.3.1

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


In de expertgroep is door een van de deelnemers onderstaande figuur aangedragen, gebaseerd op ISO/IEC 10181-3. 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. 2.3.2

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


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: https://wiki.noiv.nl/xwiki/bin/download/OpenDWR/WebHome/Realisatielij 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‟. 2.3.3

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


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 2.3.1 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


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


2.6

SAML Zoals gevraagd heeft de expertgroep in de breedte naar het domein gekeken. Hierbij is ook de standaard SAML aan de orde gekomen, een andere standaard van OASIS. Deze standaard is reeds opgenomen op de lijst voor „pas toe of leg uit‟. In de in paragraaf 2.3.1 gepresenteerde architectuur wordt SAML gedefinieerd als belangrijke standaard voor authenticatie. Op dit moment is SAML opgenomen op de lijst voor “Federatieve (web)browser-based single-sign-on (SSO) en single-sign-off.” Dit is een beperkte vorm van authenticatie. Hoewel hier destijds bij opname bewust voor gekozen is, zijn ook andere vormen van (systeem naar systeem) authenticatie mogelijk waarbij SAML een rol kan spelen. Technisch kan SAML bovendien een (beperkte vorm) van autorisatie invullen. In de discussie in de expertgroep kwam aan de orde dat vaak voorbij wordt gegaan aan het beperkte toepassingsgebied van SAML op de lijst voor „pas toe of leg uit‟. Consequentie is dan dat SAML een bredere rol krijgt toebedeeld dan oorspronkelijk was voorzien bij de opname op de lijst voor „pas toe of leg uit‟. Soms is dit terecht, maar vaak ook niet. Als er gekozen wordt voor bredere toepassing van SAML richting het domein van autorisatie, dan heeft toepassing in combinatie met XACML de voorkeur. Primair zou de scheidslijn kunnen zijn: SAML voor authenticatie, XACML voor autorisatie. Mengvormen komen echter ook voor. Zo is er een SAML 2.0 profiel voor XACML, waar eHerkenning inmiddels mee werkt. Gegeven deze situatie concludeert de expertgroep dat het – met de inzichten van nu – mogelijk zinvol is om het toepassingsgebied van SAML op te rekken. Hoe breed of hoe smal is niet op voorhand door de expertgroep gedefinieerd. Bij bijvoorbeeld eHerkenning zou het initiatief gelegd kunnen worden om een voorstel ter zake te doen. Conclusie van de expertgroep:  SAML richt zich vooral op het domein van authenticatie. Thans is de standaard voorgeschreven voor „single-sign-on‟. Er is echter een bredere toepassing van SAML mogelijk.  Bij de bredere toepassing van SAML verdient het gebruik samen met XACML aanbeveling, waarbij XACML primair wordt gebruik voor autorisatie en SAML voor authenticatie.

Pagina 21 van 29


3

Toetsing van standaard aan criteria

In de voorbereiding zijn de deelnemers gevraagd de standaarden te scoren aan de hand van de criteria uit het rapport, “Open standaarden, het proces om te komen tot een lijst met open standaarden”. Door de expertgroep is besloten de standaard WS-Policy hierbij buiten beschouwing te nemen, daar het advies is deze standaard te bezien in het kader van Digikoppeling (zie paragraaf 2.4) en niet afzonderlijk op de lijst op te nemen. Hoewel geadviseerd wordt XACML op dit moment nog niet op te nemen op de lijst, acht de expertgroep de standaard wel zeer kansrijk voor de toekomst. Op basis van de voorbereiding van de deelnemers wordt daarom in dit hoofdstuk een voorlopige score gegeven op de diverse criteria. 3.1

Openheid

3.1.1

Goedkeuring en handhaving De standaard is goedgekeurd en zal worden gehandhaafd door een nonprofit organisatie. XACML wordt beheerd door OASIS; dit is een non-profit organisatie.

De lopende ontwikkeling gebeurt op basis van een open besluitvormingsprocedure die toegankelijk is voor alle belanghebbende partijen (consensus of meerderheidsbeschikking enz.). Het OASIS-besluitvormingsproces verloopt vanuit een technische commissie (TC) en lijkt voldoende open.

3.1.2

Beschikbaarheid De standaard is gepubliceerd en over het specificatiedocument van de standaard kan vrijelijk worden beschikt of het is te verkrijgen tegen een nominale bijdrage. Het moet voor een ieder mogelijk zijn om het te kopiëren, beschikbaar te stellen en te gebruiken om niet of tegen een nominale prijs. De standaard is te downloaden via de website van OASIS. http://docs.oasis-open.org/xacml/2.0/access_control-xacml-2.0-corespec-os.pdf

Pagina 22 van 29


3.1.3

Intellectueel eigendom Het intellectuele eigendom – met betrekking tot mogelijk aanwezige patenten – van (delen) van de standaard is onherroepelijk ter beschikking gesteld op een “royalty-free” basis. In de voorbereiding is er door enkele expertgroepleden melding gemaakt van een patentkwestie. Het zou gaan om een tweetal patenten van IBM die betrekking hebben op onderdelen van de standaard. De technische commissie heeft deze delen optioneel gemaakt, zodat gebruik van het patent omzeild kan worden: “Note that the definition of Obligations in XACML was a contribution from the IBM representative to the XACML TC. At the time XACML 1.0 was under development, IBM has declared a patent it holds related to Obligations to OASIS, but did not offer royalty-free licensing terms for use in XACML implementations until August of 2005.. As a result, the XACML TC made support for Obligations in XACML optional, even though the IBM patent appears to cover only a specialized implementation.” Bron: http://labs.oracle.com/techrep/2005/smli_tr-2005147/TRCompareEPALandXACML.html

Meer informatie hierover is te vinden via: http://www.oasisopen.org/committees/xacml/ipr.php Bij een eventueel vervolg zou dit nader getoetst moeten worden. 3.1.4

Hergebruik Er zijn geen beperkingen omtrent het hergebruik van de standaard. Naar mening van de expertgroep zijn deze niet aanwezig.

3.2

Bruikbaarheid

3.2.1

Volwassenheid De standaard is voldoende uitgekristalliseerd. De standaard lijkt voldoende uitgekristalliseerd. Op afzienbare termijn wordt versie 3.0 verwacht, deze heeft nu de status van „committee specification‟. Axiomatics en BitKOO hebben hier inmiddels een implementatie van. Overwogen kan worden in plaats van de aangemelde versie (2.0) deze nieuwe versie op te nemen op de lijst. Dit zou nader onderzoek vereisen.

De verdere ontwikkeling en het onderhoud van de standaard zijn verzekerd. De standaard wordt breed ondersteund en de ontwikkeling lijkt ook op termijn verzekerd via OASIS. Pagina 23 van 29


Er is een methode waarmee conformiteit aan de standaard kan worden bepaald. De technische commissie heeft specifieke conformance tests ontwikkeld waarmee de conformiteit kan worden vastgesteld. Er is geen certificeringsprogramma. Er is voldoende praktijkervaring met het gebruik van de standaard. Hoewel de standaard breed wordt ondersteund, is de praktijkervaring nog relatief beperkt. Er is nu en in de toekomst voldoende ondersteuning door (meerdere) marktpartijen voor de standaard. Dit lijkt het geval. De standaard wordt ondersteund door alle grote softwareleveranciers. Ook zijn er open source implementaties van de standaard beschikbaar. De verwachting van het toekomstig gebruik van de standaard is positief. De expertgroep is positief ten aanzien van dit punt, gegeven de brede ondersteuning, de doorlopende ontwikkeling de internationale ondersteuning voor de standaard.

3.2.2

Functionaliteit De standaard voldoet aan de functionele eisen die aan de werking van de standaard gesteld worden binnen het voorgestelde toepassingsgebied. De standaard is goed toepasbaar voor autorisatie. Wel kunnen er aanvullende afspraken (profielen) nodig zijn, bijvoorbeeld ten aanzien van de te gebruiken attributen.

3.2.3

Standaarden Zijn er concurrerende standaarden? Zo ja, welke en door wie worden die gebruikt? Wat zijn de voor- en nadelen van deze standaard ten opzichte van concurrerende standaarden? Voor gebruik binnen organisaties kan in een aantal gevallen gebruik worden gemaakt van proprietary standaarden, die gekoppeld zijn aan het gekozen infrastructuurplatform (bijvoorbeeld autorisatie gekoppeld aan de ActiveDirectory). Hoewel dit goed en eenvoudig toepasbaar is, zijn er ook overwegingen om te kiezen voor een open standaard. Hiermee kan de afhankelijkheid van één leverancier worden verminderd. Daar staat dan wel tegenover dat mogelijk extra implementatie-inspanningen nodig zijn. In de vorige hoofdstukken is in meer detail hier op ingegaan (o.a. op de relatie met SAML).

Pagina 24 van 29


3.3

Potentieel

3.3.1

Leveranciersonafhankelijkheid Het opnemen van de standaard op de lijst draagt bij aan het vergroten van de leveranciersonafhankelijkheid. De standaard zorgt voor een minder grote afhankelijkheid van leveranciers. Enerzijds door externalisering van autorisatie, anderzijds doordat voor deze externalisering een open standaard wordt gebruikt (i.p.v. een leverancierspecifieke standaard).

3.3.2

Interoperabiliteit Het opnemen van de standaard op de lijst draagt bij aan het vergroten van de interoperabiliteit. De standaard maakt het mogelijk om autorisatie op federatief niveau, dus tussen organisaties te regelen.

3.4

Impact

3.4.1

Bedrijfsvoering Brengt de toepassing van de standaard risico's met zich mee op het gebied van de bedrijfsvoering? Het feit dat via externalisering de toegangsautorisatie buiten een applicatie wordt geplaatst brengt op zichzelf risico‟s met zich mee. In het bijzonder indien dit plaatsvindt via een externe partij (organisatorisch). Brengt de toepassing van de standaard positieve effecten met zich mee op het gebied van de bedrijfsvoering? De standaard maakt het mogelijk op een centrale plaats in een organisatie of in een netwerk van organisaties toegangsautorisaties te regelen; dit brengt mogelijk besparingen met zich mee. Daarnaast zorgt het voor een grotere uniformiteit en dus een kleinere kans op inconsistenties tussen autorisatie in verschillende applicaties.

3.4.2

Informatievoorziening Brengt de toepassing van de standaard risico's met zich mee op het gebied van de informatievoorziening? Er zijn door de deelnemers geen specifieke risico‟s benoemd. Brengt de toepassing van de standaard positieve effecten met zich mee op het gebied van de informatievoorziening? Hierbij kan gezegd worden dat door toepassing van attribuut gebaseerde autorisatie (XACML maakt dit mogelijk) tot op een groter detailniveau geregeld kan worden wie waartoe toegang heeft. Pagina 25 van 29


3.4.3

Technologische risico‟s Brengt de toepassing van de standaard technologische risico's met zich mee? Externalisering van autorisatie is een relatief jonge ontwikkeling. Bestaande applicaties zullen hier ingevoegd moeten worden. Dit brengt risico‟s met zich mee, aangezien applicaties hier niet altijd goed mee om kunnen gaan (b.v. vanwege een verouderde opzet van de software). Brengt de toepassing van de standaard positieve technologische effecten met zich mee? Externalisering van autorisatie maakt een verbetering van het applicatielandschap mogelijk. Hierbij kan verwezen worden naar de rationale van de indiener, zoals beschreven in paragraaf 2.2.

3.4.4

Beveiliging en privacy Brengt de toepassing van de standaard risico's met zich mee op het gebied van beveiliging of privacy? Externalisering van autorisatie brengt risico‟s met zich mee. Er moeten immers goede afspraken zijn over wie waartoe toegang heeft. Een overhaaste invoering van de standaard kan er toe leiden dat er onvoldoende zicht is op de diverse toegangsrechten, met alle consequenties van dien. Invoering moet daarom zeer zorgvuldig gebeuren. Brengt de toepassing van de standaard positieve technologische effecten met zich mee op het gebied van de beveiliging en privacy? Externalisering van autorisatie maakt centraal beheer mogelijk. Dit kan potentieel zorgen voor een betere beveiliging van gegevens.

3.4.5

Migratie Kan er gemakkelijk naar de standaard worden gemigreerd? Invoering in bestaande applicaties is complex. In de praktijk wordt er vooral voor nieuwe applicaties gekozen voor toepassing van een externe autorisatie / authenticatie omgeving.

Pagina 26 van 29


4

Advies aan Forum en College

4.1

Advies ten aanzien van de ingediende standaarden In deze paragraaf zal allereerst ingegaan worden op de vraag of WS-Policy en XACML naar mening van de expertgroep opgenomen zouden moeten worden op de lijst voor „pas toe of leg uit‟. Vervolgens zal in paragraaf 4.2 ingegaan worden op de nadere adviezen op het gebied van authenticatie en autorisatie.

4.1.1

WS-Policy De expertgroep adviseert WS-Policy niet op te nemen op de lijst voor „pas toe of leg uit‟. De vraag naar het (afzonderlijke) gebruik van de standaard is niet overtuigend aangetoond. Gezien de verwevenheid met andere standaarden voor webservices, ligt een koppeling met het Digikoppeling WUS-profiel (het profiel voor webserivces) voor de hand. Geadviseerd wordt de keuze over het al of niet toepassen van WS-Policy over te laten aan de beheerorganisatie voor Digikoppeling. Mocht gekozen worden voor inbedding van WS-Policy in Digikoppeling, dan kan een (op basis daarvan ontwikkelde) nieuwe versie van het Digikoppeling WUSprofiel volgens de vigerende versiebeheerprocedures vastgesteld worden.

4.1.2

XACML De expertgroep is van mening dat XACML een duidelijke doelstandaard is op het gebied van autorisatie. Voor een effectieve toepassing van de standaard is meer ervaring nodig en een architectuur waarbinnen dit kan. De expertgroep adviseert op dit moment nog niet over te gaan tot opname op de lijst voor „pas toe of leg uit‟, maar eerst meer ervaring met de standaard op te doen. Daarna kan de opname op de lijst eventueel opnieuw aan de orde komen.

Pagina 27 van 29


4.2

Aanvullende aanbevelingen De expertgroep onderstreept het belang van samenhang op het gebied van identificatie, authenticatie en autorisatie. In hoofdstuk 2 zijn een aantal conclusies getrokken op basis van een brede blik op dit domein. Primair leiden deze tot de adviezen zoals genoemd in de vorige paragraaf, maar daarnaast leiden deze conclusies ook tot een zevental aanvullende aanbevelingen. 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.

Pagina 28 van 29


7.

Ontwikkel een referentiearchitectuur voor identificatie, authenticatie en autorisatie binnen de overheid.

Voor een belangrijk deel zijn er dus eerst nog onderzoeks- en ontwikkelvraagstukken die opgelost moeten worden, voordat gekeken kan worden naar standaardisatie van het geheel. De leden van de expertgroep zijn bereid om na invulling van deze aanvullende adviezen en op basis van de resultaten van de aanvullende onderzoeken zich in 2012 nogmaals te buigen over de vraag of XACML opgenomen moet worden op de lijst voor „pas toe of leg uit‟.

Pagina 29 van 29

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

Recommend Documents