Inleiding Autorisatie

In beginsel is autorisatie eenvoudig: iemand wil bij iets en de vraag is of dat mag.

Autorisatie op zijn basis

Was het maar zo gemakkelijk.

• ‘iemand’ betekent dat bekend moet zijn wie diegene is. Dit vraagt om identificatie, identificerende gegevens, identiteiten. Het proces om dit te verifiëren heet authenticatie en dat is een onderwerp op zich.
• Het ‘iets’ betekent ‘een resource’. Dat kan een hele dataset zijn, bijv. een basisregistratie als BAG, BGT of BRK. Het kan ook een specifieke selectie zijn uit een dataset of een selectie uit de combinatie van meerdere datasets. Dat ‘iets’ is al snel complex.

Veel gehanteerde termen zijn ‘subject’ voor ‘de iemand die de vraag stelt'. ‘Resource’ wordt gebruikt voor het ‘iets dat opgevraagd wordt’. De autorisatie wordt bepaald door ‘policies’, de voorwaarden, waaronder het subject toegang krijgt of niet. Deze gaan uit van een ‘context’ waarin de ‘rollen’ van het ‘subject’ en extra informatie op basis van het ‘request’, de vraag, kunnen worden meegenomen in de afweging. Deze terminologie is formeel vastgelegd in XACML.

Subject

Een subject kan een gebruiker zijn en ook een machine (computer). Afhankelijk van het type bestaan er verschillende soorten van identiteiten.

Subject

Gebruikers worden meestal beheerd in een ‘User Management System’, welke weer gevoed kan worden door een HR systeem. Daarin worden meestal ook functies en rollen bijgehouden en uitgegeven door de beheerorganisatie over wat ‘iemand mag’. Een gebruiker heeft dan een ‘username’ (en wachtwoord) en een set aan rollen. Een geautoriseerd persoon geeft toestemming en legt verantwoording af over de rechten (rollen) van een gebruiker.

Machines worden vaak dmv certificaten of (API) ‘keys’ (sleutels) geïdentificeerd. Deze zijn uitgegeven door een autoriteit en zijn geautomatiseerd te controleren.

Zowel gebruikersaccounts als sleutelbeheer zijn complexe beheersprocessen waarin vele lagen van (verborgen) complexiteit zitten, zoals het kunnen intrekken, delegeren, verschillende niveaus van vertrouwen passend bij de verschillende niveaus van betrouwbaarheid die nodig is, etc, etc.

Out of scope
Voor het Lock-Unlock project hebben we het onderdeel 'Subject' en ook het proces van authenticatie aangenomen als beschikbaar. Dat is er. Dat bestaat gewoon. Dit is absoluut niet het geval en er valt juist heel veel over te zeggen. Maar voor de scope van dit project is dat niet relevant. Op enig manier wordt een user of machine geïndentificeerd en dat vindt plaats vóórdat het onderdeel autorisatie komt. Dit laatste is juist het onderwerp van onderzoek voor Lock-Unlock.

Doelbinding

Het doel van autorisatie, zeker in de context van de overheid, is te garanderen dat deze toegang rechtmatig is. Daarvoor wordt o.a. gekeken naar interne en externe beleidstukken en wet- en regelgeving. Een belangrijk aspect hierbij is de doelbinding, zeker als het om persoonsgegevens gaat: gegevens mogen alleen worden verwerkt en verzameld voor een specifiek en gerechtvaardigd doel. Dat wil zeggen dat er een juridische grondslag is voor de toegang en/of verwerking.

Het blijkt echter onmogelijk om volledig van tevoren te kunnen bepalen of de grondslag voldoende is om toegang te kunnen verlenen. Dat heeft te maken met de gedeelde verantwoordelijkheid van die toegang als dat een koppeling tussen twee organisaties betreft. Het punt is dat de doelbinding per casus gebonden is. Het is voor de data-leverende organisatie echter niet mogelijk om te beoordelen of de specifieke casus waar de betreffende gebruiker van de data-vragende organisatie mee bezig is, passend is voor het doel dat beoogd is. Sterker nog, het weten van die specifieke casus gaat juist in tegen de regels van doelbinding, juridische grondslag en AVG. Vooraf specifieke doelbinding controleren is daarom niet (volledig) mogelijk.

Autorisatie

Autorisatie is de controle en het proces van toegang geven tot een Resource. Het doel van autorisatie is dat alleen vastgestelde toegang verleend wordt aan Subjecten. Dat is een proces van afscherming vóóraf. Aangezien de doelbinding vooraf niet volledig kan worden gecontroleerd, wordt er een afgeleide daarvan gemaakt op een hoger niveau dan specifieke casussen. Een hele organisatie krijgt toegang tot de gehele dataset van een andere organisatie. Om deze toegang te controleren en bij te sturen zodat de juridische grondslag passend is bij de autorisatie, is auditing noodzakelijk.

Een subject krijgt dus niet zomaar toegang tot een resource. En deze afschermings- of toegangsregels kunnen worden beschreven in policies, de autorisatieregels. Welke regels zijn er? Zijn deze te standaardiseren? Zijn deze als data te declareren? Nog beter: als Linked Data? Dit is het onderwerp van onderzoek voor het Lock-Unlock project.

Autorisatie

Auditing

Zoals hierboven al gesteld bij doelbinding, is het onmogelijk om van tevoren of bij de evaluatie om toegang te gaan verlenen te bepalen of dat rechtmatig is. De enige mogelijkheid om de grondslag juist te kunnen controleren, is achteraf. In dat geval is auditing noodzakelijk op de toegang die gegeven is. Voorkomen is dan helaas niet meer mogelijk, maar wel bijsturing en eventueel opvolging.

Voor de auditing zijn beide partijen nodig en verantwoordelijk. De partij / organisatie van waaruit de bevraging wordt gedaan, is verantwoordelijk voor het vastleggen van de relatie naar de specifieke grondslag en specifieke casus waarvoor die grondslag zou moeten gelden en de medewerker die vanuit die organisatie daarbij betrokken is. De partij / organisatie die bevraagd wordt, de leverende partij, dient vast te leggen dat zij bevraagd zijn door de vragende partij en voor welke resource dat precies was. Om dmv een audit de relatie tussen beide verslaglegging te kunnen doen, wordt er vanuit de bevragende partij een transactie referentie (of id) meegegeven die in beide verslagleggingen dient te worden bewaard. Deze verslaglegging wordt ook wel 'logging' genoemd.

De grondslag of doelbinding is op dit moment niet “machine readable” en de relatie met het datamodel is niet formeel vastgelegd. Er wordt wel aan gewerkt om dat te standaardiseren in de GEMMA Verwerkingenlogging.

Resource

Bij een ‘resource’ denken we in eerst instantie al snel aan een ‘tabel’. Een set aan gegevens van rijen en kolommen.

Resource

Was het maar zo eenvoudig... Meestal is een 'set of data’, een verzameling tabellen. In veel gevallen is er een volledige informatiemodel (IM) of datamodel ontworpen om alle relaties tussen deze tabellen nauwkeurig en volledig weer te geven. De verschillende objecten in het model hebben elk hun eigen tabel en worden in de tabel impliciet gedefinieerd door sleutelkolommen. Zo'n hele verzameling gerelateerde objecten en een set gegevens wordt een dataset genoemd. Voorbeelden: de basisregistraties zoals BRK, BAG, BGT.

In deze context is een resource een database die een of meer tabellen bevat.

Resource: Tabel, Dataset, Database

Een tabel of een dataset zit meestal in een database.

Resource - Database

Goed gebruik is om deze niet direct toegankelijk te maken voor gebruikers, maar te voorzien van een Application Programming Interface (API). Een API is een technisch koppelvlak die mogelijkheden biedt voor het opvragen (en muteren) van data en daar ook controles en beperkingen aan kan stellen. Hoewel API een generiek concept is, wordt in de huidige staat van de technologie meestal een ‘REST API’ bedoeld.

Een API kan bijvoorbeeld een beperkt deel van de data(base) beschikbaar maken. Hierin is een verschil tussen horizontale en verticale scheiding (segmentatie). Horizontale scheiding betekent dat niet alle rijen op te vragen zijn. In het kader van autorisatie zou dat bijvoorbeeld beperkt kunnen zijn tot een bepaalde regio, bijvoorbeeld gemeentelijke grenzen. Een verticale scheiding betekent dat niet alle kolommen op te vragen zijn. Een voorbeeld hiervan is dat perceelinformatie als open data beschikbaar is, maar de persoonsgegevens (uiteraard) niet. Deze zijn alleen op te vragen met de juiste rechten, of eigenlijk: de juiste grondslag. In deze context is de resource de combinatie van database en (REST) API.

Resource: Triples

Een resource kan een ingewikkeld informatiemodel hebben en het wordt nog ingewikkelder als meerdere datasets gecombineerd moeten worden. Dat betekent dat er relaties tussen meerdere informatiemodellen moeten worden gelegd.

Database to triples

Linked Data is een concept en technologie die hier veel flexibiliteit en expliciete ondersteuning voor biedt. In plaats van tabellen wordt hierin de data ‘uit elkaar gehaald’ tot zogenaamde ‘triples’. Elke data instantie is een ‘subject’ dat een relatie heeft (‘predicate’) tot een ‘object’. En dit kan oneindig! Zo kunnen relaties leiden tot een object die attributen beschrijft zoals in een meer traditioneel informatiemodel en een tabel in een database.

In deze context wordt een triple als een resource beschouwd.

Resource - Triple

Let Op: een resource wordt in de terminologie van Linked Data anders gedefinieerd dan in de context van dit rapport. Zie de Linked Data beschrijving voor meer informatie. In de context van deze documentatie wordt niet de definitie van resource zoals gedefinieerd in Linked Data gebruikt.

Het object in de ene triple kan het subject worden in een ander, waarbij het predicate dit subject aan een ander object koppelt of een attribuut van dit subject beschrijft. Wanneer twee of meer triples met elkaar verbonden zijn, resulteert dit in een ‘graph’ (graaf). Op deze manier kunnen triples informatie/data met elkaar verbinden, ook wanneer deze oorspronkelijk in verschillende tabellen stonden. De graph die zo ontstaat, kan gebruikt worden om te ‘navigeren’ van subject naar object naar subject naar object.

Resource: SPARQL Endpoint

Een graph wordt opgeslagen in een specifieke database, namelijk een ‘triple store’. Ook deze wordt niet direct ontsloten voor gebruikers, maar beveiligd en afgeschermd door een API. Voor Linked Data is een ‘SPARQL API’ of ‘SPARQL endpoint’ een veelgebruikte API. SPARQL is een ‘query language’, een vraagtaal voor Linked Data obv internet technologie (oa HTTP).

In deze context is de resource de graph en het bijbehorende SPARQL API / endpoint.

Resource - SPARQL Endpoint

Een bijzondere toegevoegde waarde van het publiceren van data als Linked Data is het federatief kunnen bevragen van data. Datasets zijn vrijwel altijd opgeslagen in silo’s. Mbv Linked Data kunnen datasets gemakkelijk aan elkaar gerelateerd worden en op een federatieve manier in één keer bevraagd worden. De Kadaster Knowledge Graph is hier een voorbeeld van met de BRK, BGT, BRT en BAG gekoppelde datasets.

De koppeling van elke graph (of resource) vereist de opname van een gedeeld identificerend sleutelveld of attribuut (zie informatiekundige kern). In onderstaande figuur zijn deze attributen of sleutelvelden gedefinieerd als een BSN- of KvK-nummer waarmee drie verschillende graphs met elkaar in verband kunnen worden gebracht. Met behulp van deze velden kan één enkele query worden geschreven, verwijzend naar elke SPARQL API en het relevante sleutelveld, om zo de benodigde informatie uit drie bronnen op te halen.

In deze context is de resource - elke triple, een hele dataset, de gekoppelde datasets, wellicht een selectie uit een dataset - de resource is hier niet eenduidig.

Resource - SPARQL Endpoints

Een resource is dus nog niet zo eenvoudig. Er is hier ook een gelaagdheid in te beschrijven. Het meest elementaire onderdeel is een triple. Gerelateerde triples vormen een graph voor een subset van gerelateerde gegevens, traditioneel vaak een object of tabel genoemd. Alle triples en graphs binnen één context vormen een dataset. Zo’n dataset is ontsloten met een bijbehorende API, wat deze in een silo plaatst. Wanneer een dataset relaties naar andere datasets bevat, kunnen refereerde datasets via hun eigen API bevraagd worden. Een selectie uit één dataset wordt een subset genoemd. Gerelateerde selecties over meerdere datasets heen wordt ook subset genoemd en soms superset.

In het kader van het afschermen van gegevens en het autoriseren van de juiste mensen (en machines) met de juiste rechten om deze afgeschermde gegevens juist wél op te vragen, is deze gelaagdheid van belang. Afscherming en autorisatie in de technologie van nu, voornamelijk REST API’s, is binair: je hebt toegang of je hebt het niet. En dat is dan voor de gehele API. Om toch onderscheid en variaties te kunnen doen, worden meerdere API’s gepubliceerd voor specifieke doeleinden of doelgroepen.

Resource - Samenvatting

Met SPARQL API’s is het mogelijk om vrije queries (vragen) te stellen per dataset/-silo of over datasets heen. Autorisaties en variaties in doelgroepen is hierin echter veel ingewikkelder. Dit is precies het onderwerp van dit project.

Zie ook de glossary voor de verschillen tussen dataset, subset, database, graph en subgraph

In de volgende sectie worden enkele van de bestaande implementaties van autorisatie voor federatieve eindpunten besproken. Deze zijn niet uitputtend, maar geven een indicatie van de huidige benaderingen.