GOA Een architectuur voor authenticatie en autorisatie van burgers en bedrijven voor de overheid (een tussenstand) Kees de Jong Overheden en overheidsinstellingen bieden burgers en bedrijven in toenemende mate de mogelijkheid om hun diensten elektronisch af te nemen en steeds meer burgers en bedrijven maken hiervan gebruik. Ter ondersteuning hiervan zijn er door de Nederlandse overheid een drietal landelijke voorzieningen ontwikkeld te weten: DigiD, DigiD Machtigen en eHerkenning. De verschillende voorzieningen zijn echter los van elkaar ontwikkeld en hoewel ze gebruik maken van dezelfde technieken en uitgangspunten werken ze allemaal net even anders. Van een eenduidige architectuur voor authenticatie en autorisatie is geen sprake. Dit is een ongewenste situatie voor gebruikers van deze voorzieningen en daarom is er een initiatief gestart om een eenduidige architectuur te ontwikkelen. Binnen het project GOA (Gemeenschappelijk Ontwerp Authenticatie en Autorisatie) hebben architecten van de landelijke voorzieningen, ondersteund door architecten van dienstenaanbieders en marktpartijen, juristen en externe authenticatie- en autorisatie experts deze architectuur vorm gegeven.
Inleiding Het palet aan partijen die gebruik maken van de elektronische dienstverlening van de overheid is heel breed en gevarieerd. Dit loopt van een burger die op een gemeentelijke website een uittreksel opvraagt uit het bevolkingsregister tot een multinational die vanuit eigen software applicaties (via system to system koppelvlakken) rapporteert aan overheidsinstanties.
Authenticatie en autorisatie Voordat een overheidsdienstverlener een elektronische dienst aan een partij beschikbaar stelt wil hij twee dingen zeker weten: 1. Wie is de partij die de dienst af wil nemen (authenticatie) 2. Is deze partij bevoegd om de dienst af te nemen (autorisatie) Bij het afnemen van een dienst zijn er in principe maar twee mogelijkheden: •
de partij die zich authenticeert bij de dienstverlener handelt namens zichzelf en is dus zelf de belanghebbende van de dienst.
•
de partij die zich authenticeert bij de dienstverlener zegt gemachtigd (geautoriseerd) te zijn om namens een andere partij te mogen handelen en is dus zelf geen belanghebbende.
www.via-nova-architectura.org
December 2011
1
Ter ondersteuning van authenticatie en autorisatie zijn er door de Nederlandse overheid een drietal landelijke voorzieningen ontwikkeld: 1. DigiD DigiD regelt dat burgers zich digitaal kunnen identificeren bij de overheid. 2. DigiD Machtigen DigiD Machtigen regelt dat burgers andere burgers en bedrijven kunnen machtigen om namens hen bepaalde elektronisch zaken te regelen met de overheid. 3. eHerkenning eHerkenning is een stelsel van afspraken. Deze voorziening wordt niet gerealiseerd door de overheid maar door meerdere marktpartijen. eHerkenning regelt dat bedrijven zich digitaal kunnen identificeren bij de overheid en geeft aan of medewerkers gemachtigd zijn om namens het bedrijf te handelen. Tevens regelt eHerkenning dat bedrijven andere bedrijven kunnen machtigen om namens hen bepaalde elektronisch zaken te regelen met de overheid. Daarnaast kunnen een geselecteerd aantal Certification Service Providers (CSP’s) een PKI-O certificaat (met OIN) uitgeven op basis van De Staat Der Nederlanden. Een bekend en ondertussen berucht voorbeeld hiervan is het bedrijf DigiNotar. Met een PKI-O certificaat kunnen zowel overheidspartijen als bedrijven zich in een system-to-system situatie authenticeren. Daarnaast kan het certificaat gebruikt worden voor ondertekening. Met ondertekening wordt bedoeld dat de opsteller van een bericht bekend is en dat de inhoud van dit bericht niet ongemerkt gewijzigd kan worden. De verschillende voorzieningen zijn los van elkaar ontwikkeld en hoewel ze gebruik maken van dezelfde technieken en uitgangspunten werken ze allemaal net even anders. Van een eenduidige architectuur voor authenticatie en autorisatie is geen sprake. Daar komt nog bij dat verschillende dienstenaanbieders deze voorzieningen op verschillende manieren hebben geïmplementeerd bij de inrichting van hun business processen. Voor software ontwikkelaars die software ontwikkelen die koppelen met dienstenaanbieders, betekent dit dat zij afhankelijk van de dienstenaanbieder een andere oplossing of koppeling moeten implementeren. Dit is een ongewenste situatie en daarom is er een initiatief gestart om hiervoor een eenduidige architectuur te ontwikkelen binnen een breed samenwerkingsverband van architecten van de landelijke voorzieningen, ondersteund door architecten van dienstenaanbieders en marktpartijen, juristen en externe authenticatie en autorisatie experts: het project Gemeenschappelijk Ontwerp Authenticatie en Autorisatie (GOA). Dit artikel geeft een tussenstand weer in het proces van het komen tot een definitief en breed gedragen oplossingsrichting.
Frontend en backend In de architectuur van GOA wordt onderscheid gemaakt tussen een ‘frontend’ en een ‘backend’. Het frontend (Human2System) kan door een willekeurige partij worden vormgegeven. Het backend (System2System) levert de gevraagde dienst en wordt altijd door een dienstenaanbieder vormgegeven.
www.via-nova-architectura.org
December 2011
2
Vertrouwde en niet vertrouwde partijen Binnen GOA wordt onderscheid gemaakt tussen vertrouwde partijen en niet vertrouwde partijen. De door GOA erkende vertrouwde partijen zijn: •
DigiD
•
DigiD Machtigen
•
eHerkenning
•
Overheidsdienstaanbieders
Voor een vertrouwde partij geldt: •
Een vertrouwde partij hoeft (in de regel) zijn bevoegdheid niet aan te tonen maar ontleent deze aan het feit dat het een vertrouwde partij is.
•
Een verklaring afgegeven door een vertrouwde partij is een geldige verklaring.
Voor een niet vertrouwde partij geldt: •
De identiteit wordt vastgesteld door een vertrouwde partij.
•
Indien de handelende partij niet de belanghebbende is dan dient de handelende partij haar bevoegdheid aan te kunnen tonen met een bevoegdheidsverklaring die afgegeven is door een vertrouwde partij of door de belanghebbende.
Rollen Binnen GOA wordt een aantal rollen onderkend: Handelende persoon Degene die handelingen verricht ten behoeve van het tot stand komen van een elektronische transactie met een dienstenaanbieder, als onderdeel van totstandkoming van een transactie resp. dienst. De handelende persoon kan twee rollen vervullen namelijk die van belanghebbende of die van gemachtigde. Belanghebbende Degene wiens belang rechtstreeks bij een transactie is betrokken. Gemachtigde Degene die op grond van een machtiging namens de belanghebbende transacties verricht.
Verklaringen Het belangrijkste architectuurprincipe dat binnen GOA wordt gehanteerd is dat een dienstenaanbieder een dienst uitsluitend levert op basis van actuele verklaringen die hem worden aangereikt door de aanroepende partij. Deze aanroepende partij kan bijvoorbeeld de eigen webapplicatie zijn van de dienstenaanbieder, maar ook de software van een fiscaal intermediair of een multinational. In alle gevallen wordt het verlenen van toegang tot de dienst (autorisatie) beoordeeld op basis van de aangeleverde verklaringen. Elke verklaring heeft als kenmerk dat zij een bepaalde betrouwbaarheid heeft en dat zij is ondertekend en afgegeven door een bepaalde partij. Ondertekening vindt plaats met een PKIO certificaat. Een afgegeven verklaring heeft maar een beperkte ‘levensduur’ (binnen GOA zijn dat enkele tientallen seconden). De dienstenaanbieder bepaalt aan welke eisen de betrouwbaarheid, ondertekening en de levensduur van een verklaring minimaal moet voldoen om de dienst te kunnen afnemen. Deze eisen zijn per dienst op te vragen uit een dienstenregister.
www.via-nova-architectura.org
December 2011
3
Binnen GOA spelen vier verklaringen een rol: 1. De business transactie 2. De identiteitsverklaring 3. De bevoegdheidsverklaring 4. De associatieverklaring
1. De business transactie De inhoud van de business transactie betreft altijd de belanghebbende en een verwijzing naar de belanghebbende is daarom altijd een onderdeel van de inhoud. De dienstenaanbieder heeft deze inhoud nodig om de dienst überhaupt uit te kunnen voeren. Een voorbeeld van een business transactie zijn de gegevens van een aangifte Inkomstenbelasting voor een bepaalde belanghebbende. De ondertekening van de business transactie kan plaats vinden door bijvoorbeeld de webapplicatie van de dienstenaanbieder waaraan de handelend persoon te kennen heeft gegeven dat hij deze transactie wil uitvoeren, de software van een fiscaal intermediair, de directeur van een onderneming met zijn eigen PKI certificaat, etc. Bij de betrouwbaarheid gaat het om de mate van betrouwbaarheid van de wilsuiting. Deze wordt gedeeltelijk bepaald door wie de business transactie ondertekent en gedeeltelijk door het proces dat gevolgd is om de wilsuiting vast te stellen. Een voorbeeld van een wilsuiting is het aanvinken van een checkbox met de tekst: “ik verklaar dat deze gegevens naar waarheid zijn ingevuld”. Er bestaat momenteel nog geen eenduidige taxonomie om de betrouwbaarheid eenduidig te definiëren.
2. De identiteitsverklaring De identiteitsverklaring gaat altijd over de handelende partij. Immers de dienstenaanbieder moet met voldoende zekerheid kunnen vaststellen wie de dienst aanvraagt. De identiteitsverklaring speelt ook een belangrijke rol bij het vaststellen van de bevoegdheid. Wanneer namelijk de handelende partij ongelijk is aan de belanghebbende dient de handelende partij een bevoegdheidsverklaring te overleggen. Een identiteitsverklaring kan afgegeven en ondertekend zijn door de handelende partij zelf (met zijn eigen PKI-O certificaat) of door een vertrouwde partij: DigiD of eHerkenning. Identiteitsverklaringen die door andere partijen zijn afgegeven of ondertekend worden niet geaccepteerd. De betrouwbaarheid van de verklaring geeft aan met welke betrouwbaarheid de identiteit is vastgesteld. Voor het vaststellen van het betrouwbaarheidsniveau wordt STORK (zie www.eidstork.eu) gevolgd.
3. De bevoegdheidsverklaring Indien de belanghebbende en de handelende partij niet overeenkomen, dient de handelende partij een bevoegdheidsverklaring te overleggen. De betrouwbaarheid van de bevoegdheidsverklaring wordt bepaald door de betrouwbaarheid van het proces waarmee de machtiging is vastgelegd. Een bevoegdheidsverklaring mag afgegeven en ondertekend worden door een vertrouwd machtigingenregister (DigiD Machtigen of eHerkenning) of door de belanghebbende zelf. (bijvoorbeeld een multinational die een eigen online machtigingenregister heeft dat een bevoegdheidsverklaring kan afgeven conform de GOA standaard). Een machtigingenregister is zelf ook een dienstenaanbieder en zal een bevoegdheidsverklaring dus ook alleen maar afgeven op basis van de juiste verklaringen. Bij een machtiging spelen 3 partijen een rol: de gemachtigde, de vertegenwoordigde en de dienstenaanbieder. Elk van
www.via-nova-architectura.org
December 2011
4
deze partijen is voor het machtigingenregister een belanghebbende die dus een bevoegdheidsverklaring mag opvragen.
4. De associatieverklaring Het doel van de associatieverklaring is om de verschillende andere verklaringen te bundelen en deze samenstelling niet meer wijzigbaar te maken. Dit voorkomt misbruik van de andere verklaringen. De associatieverklaring wordt opgesteld door de software die de verschillende verklaringen verzamelt. In de meeste gevallen zal dit de software zijn die ook het frontend implementeert, maar het kan ook een aparte herbruikbare component zijn. De ondertekening kan plaatsvinden door de dienstenaanbieder of door de handelende partij. Indien de handelende partij niet de belanghebbende is dient deze over een bevoegdheidsverklaring te beschikken.
Bevoegdheidsketen Een business transactie-, identiteits- of associatieverklaring komt binnen één transactie maar één keer voor. Een bevoegdheidsverklaring kan echter meerdere keren voorkomen. Deze situatie ontstaat wanneer een bevoegdheid of machtiging gedelegeerd wordt. Bijvoorbeeld bedrijf A machtigt bedrijf B om namens haar een bepaalde aangifte te doen en Bedrijf B machtigt op haar beurt Bedrijf C om dat voor bedrijf A te doen. Er moeten dan twee machtigingen gekoppeld worden vastgelegd: die van A naar B en die van B naar C. Wanneer bedrijf C als handelende partij namens belanghebbende A optreedt, dient bedrijf C twee bevoegdheidsverklaringen te overleggen, die van A naar B en die van B naar C.
GOA in de praktijk Aan de hand van een aantal generieke scenario’s wordt duidelijk hoe GOA in de praktijk werkt.
Scenario 1 Meneer de Bruin doet een eigen aangifte via het online portaal van een Overheidsdienstverlener. Meneer de Bruin is zowel de handelende partij als de belanghebbende. Een bevoegdheidsverklaring is dus niet nodig. Voor de authenticatie van meneer de Bruin maakt het portaal van de Overheidsdienstverlener gebruik van DigiD. Die levert de benodigde identiteitsverklaring. Het portaal zal de verschillende verklaringen samenvoegen en voorzien van een associatieverklaring aanbieden aan het backend van de Overheidsdienstverlener. Ondertekening De business transactie en de associatieverklaring zijn ondertekend door de Overheidsdienstverlener. De identiteitsverklaring is ondertekend door DigiD.
Scenario 2 Meneer de Bruin doet aangifte voor zijn buurvrouw mevrouw de Wit via het online portaal van een Overheidsdienstverlener. Meneer de Bruin is de handelende partij maar niet de belanghebbende. Hij heeft dus een bevoegdheidsverklaring nodig dat hij namens mevrouw de Wit aangifte mag doen.
www.via-nova-architectura.org
December 2011
5
Het verschil met scenario 1 is dat het portaal van de Overheidsdienstverlener bij DigiD Machtigen een bevoegdheidsverklaring zal opvragen voor meneer De Bruin. De machtiging die mevrouw De Wit heeft gegeven aan Meneer De Bruin, is op een eerder moment vastgelegd in DigiD Machtigen
Figuur 1 Een burger handelt namens zichzelf of als gemachtigde (Scenario 1 & 2)
Scenario 3 Mevrouw de Zwart medewerker van het bedrijf Vink BV doet voor Vink BV aangifte via het online portaal van een Overheidsdienstverlener. Voor de Overheidsdienstverlener is mevrouw de Zwart niet interessant. Voor de Overheidsdienstverlener is de handelende partij Vink BV. Vink BV is zowel de handelende partij als de belanghebbende. Een bevoegdheidsverklaring is dus niet nodig. Voor de authenticatie van Vink BV zal het portaal van de Overheidsdienstverlener gebruik maken van eHerkening. Mevrouw de Zwart zal gebruik maken van het aan haar uitgereikte eHerkenningsmiddel om aan te tonen dat zij gerechtigd is om namens Vink BV te handelen. eHerkenning levert de benodigde identiteitsverklaring voor Vink BV. Het portaal zal de verschillende verklaringen samenvoegen en voorzien van een associatieverklaring aanbieden aan het backend van de Overheidsdienstverlener.
www.via-nova-architectura.org
December 2011
6
Ondertekening De business transactie en de associatieverklaring zijn ondertekend door de Overheidsdienstverlener. De identiteitsverklaring is ondertekend door eHerkenning.
Scenario 4 Mevrouw de Zwart, medewerker van het bedrijf Vink BV doet, via het online portaal van een Overheidsdienstverlener, aangifte voor mevrouw de Wit. Vink BV is de handelende partij maar niet de belanghebbende. Vink BV heeft dus een bevoegdheidsverklaring nodig dat zij namens mevrouw de Wit aangifte mag doen. Het verschil met scenario 3 is dat het portaal van de Overheidsdienstverlener bij bij DigiD Machtigen een bevoegdheidsverklaring zal opvragen voor Vink BV.
Figuur 2 Een bedrijf handelt namens zichzelf of als gemachtigde (scenario 3 & 4)
Scenario 5 Mevrouw Groen, medewerkster van Koekoek NV, maakt een aangifte van Koekoek NV op in het eigen administratiepakket van Koekoek NV en verzendt deze vanuit dit pakket naar een Overheidsdienstverlener. Voor de Overheidsdienstverlener is mevrouw Groen niet interessant. Voor de Overheidsdienstverlener is de handelende partij Koekoek NV.
www.via-nova-architectura.org
December 2011
7
Koekoek NV is zowel de handelende partij als de belanghebbende. Een bevoegdheidsverklaring is dus niet nodig. Het samenstellen van de business transactie en het opstellen van de identiteitsverklaring van Koekoek NV wordt uitgevoerd door het eigen administratiepakket van Koekoek NV. Het administratiepakket zal de verschillende verklaringen samenvoegen en voorzien van een associatieverklaring aanbieden aan het backend van de Overheidsdienstverlener. Ondertekening De business transactie, de identiteitsverklaring en de associatieverklaring zijn ondertekend door Koekoek NV.
Scenario 6 Mevrouw Groen, medewerkster van Koekoek NV, maakt een aangifte van Duif BV op in het eigen administratiepakket van Koekoek NV en verzendt deze vanuit dit pakket naar de Overheidsdienstverlener. Koekoek NV is de handelende partij maar niet de belanghebbende. Koekoek NV heeft dus een bevoegdheidsverklaring nodig dat zij namens Duif BV aangifte mag doen. Het verschil met scenario 5 is dat het administratiepakket van Koekoek NV bij eHerkenning een bevoegdheidsverklaring zal opvragen voor Koekoek NV. Een andere mogelijkheid is dat Duif BV over een eigen machtigingenregister beschikt. In dat geval kan Koekoek NV bij dit register een bevoegdheidsverklaring opvragen.
www.via-nova-architectura.org
December 2011
8
Figuur 3 een bedrijf maakt gebruik van eigen software voor zichzelf en als gemachtigde (scenario 5 & 6)
Scenario 7 De firma Koekoek NV heeft het eigen administratiepakket vervangen door een SaaS applicatie van de firma Wulk BV. Mevrouw Groen medewerkster van Koekoek NV maakt een aangifte van Koekoek NV op in deze SaaS applicatie en verzendt de aangifte vanuit deze applicatie naar een Overheidsdienstaanbieder Op dit moment komen er steeds meer Cloud Computing oplossingen. Een van de Cloud Computing mogelijkheden is Sofware as a Service (SaaS). Bij een echte SaaS oplossing wordt alleen het gebruik (Pay per View) van de software in rekening gebracht. Het eigenaarschap en het beheer van de software liggen bij de SaaS aanbieder. Als we er vanuit gaan dat Wulk BV alleen gebruik maakt van zijn eigen certificaat dan is voor de Overheidsdienstverlener de handelende partij de SaaS applicatie van Wulk BV. Wulk BV is echter niet de belanghebbende, dus heeft Wulk BV een bevoegdheidsverklaring van Koekoek NV nodig dat zij namens Koekoek NV de aangifte mag doen. Het samenstellen van de business transactie en het opstellen van de identiteitsverklaring van Wulk BV wordt uitgevoerd door de SaaS Applicatie van Wulk BV. De SaaS applicatie van Wulk BV zal bij eHerkenning een bevoegdheidsverklaring opvragen waaruit blijkt dat zij gemachtigd is om namens Koekoek NV de aanvraag in te dienen. De SaaS applicatie zal de verschillende verklaringen samenvoegen en voorzien van een associatieverklaring aanbieden aan het backend van de Overheidsdienstverlener.
www.via-nova-architectura.org
December 2011
9
Ondertekening De business transactie, de identiteitsverklaring en de associatieverklaring zijn ondertekend door Wulk BV. De bevoegdheidsverklaring is ondertekend door eHerkenning.
Figuur 4 Cloud computing (scenario 7)
Inperken van bevoegdheden In de huidige opzet van GOA wordt geen nuancering aangebracht in de bevoegdheid die een handelende partij bezit. Een partij is bevoegd of is dit niet. In de dagelijkse praktijk is een nuancering echter regelmatig gewenst. Bijvoorbeeld Partij A mag een exportvergunning aanvragen namens Partij B, maar dan alleen voor de EU en met een maximum van 100.000 euro. Het realiseren van deze bevoegdheidsbeperking wordt momenteel niet gezien als een verantwoordelijkheid van de dienstaanbieder, maar als de verantwoordelijkheid van de frontend applicatie. Het is dus aan de frontend applicatie om deze beperkingen af te dwingen. Een apart geval is een medewerker van een bedrijf die namens dit bedrijf handelt. Al eerder is vermeld dat deze voor de dienstaanbieder niet de handelende partij is. Ook voor een
www.via-nova-architectura.org
December 2011
10
medewerker geldt dat eventuele beperkingen door de frontend applicatie moeten worden afgedwongen.
GOA gebruiken binnen GOA DigiD, DigiD Machtigen en eHerkenning zijn zelf ook dienstaanbieders en dus zullen zij net als alle andere dienstaanbieders hun diensten uitsluitend aanbieden op basis van verklaringen.
Conclusie De GOA architectuur is simpel, elegant en flexibel en is op papier toepasbaar gebleken in elk tot nu toe onderkend scenario. Zelfs een nieuwe trend zoals een SaaS oplossing blijkt hierin naadloos te passen. De GOA architectuur is nu in hoofdlijnen beschreven, maar het zal nog een grote inspanning vergen om deze ook daadwerkelijk te implementeren. Deze implementatie zal moeten worden doorgevoerd terwijl de verschillende winkels open blijven. Dat vergt een complexe afstemming tussen de landelijke voorzieningen onderling en hun gebruikers. Binnen GOA wordt er van uit gegaan dat de randvoorwaarden voor het afnemen van een dienst zijn vastgelegd in een dienstencatalogus. Binnen de overheid zijn verschillende van deze dienstencatalogi aanwezig. Echter ook daarvoor geldt dat deze niet zijn ontwikkeld vanuit een eenduidige architectuur, waardoor elke dienstencatalogus zelf een architectuur heeft ontwikkeld. Om GOA effectief in te kunnen zetten zal ook op het gebied van de dienstencatalogus een gemeenschappelijke architectuur moeten worden ontwikkeld. De huidige stand van de GOA architectuur is tot stand gekomen door middel van vele discussies en door inbreng van een groot aantal mensen uit verschillende organisaties en disciplines. Met name de volgende personen hebben hieraan (in alfabetische volgorde) een belangrijke bijdrage geleverd: Vincent Jansen, Kees de Jong, Frans de Kok, Arthur van de Krabben, Hans-Rob de Reus en Paul Schlotter.
www.via-nova-architectura.org
December 2011
11
