Architectuur #

Als architectuur heeft FTV gekozen voor het patroon van Externalized Access Management. Dit omvat onder andere architectuurpatronen zoals PBAC, ABAC en ReBAC.

Hieronder beschrijven we hoe deze architectuur er in federatieve context uit ziet, beginnend vanaf een generiek koppelvlak.

Generieke architectuur van een koppelvlak #

In generieke zin is de architectuur van elke API-koppeling te beschrijven in onderstaand diagram:

Links zien we de afnemer, het systeem dat om gegevensverwerking vraagt, en rechts de aanbieder, die de dienst levert. ‘Verwerking’ bedoelen we hier in de brede AVG zin: dat kan opvragen van gegevens zijn, maar ook aanpassen of verwijderen daarvan.

Beide kanten hebben in principe dezelfde componenten. Beide kanten hebben een API-gateway waarmee de andere kant gevonden en de verbinding beveiligd kan worden. Bij de beveiliging hoort in de overheidssituatie altijd een OIN PKI-certificaat. Daarnaast is er een vorm van identificatie en authenticatie: het vaststellen en verifiëren van de identiteit van de vrager. Dit kan ingebouwd zijn in de applicatie/API, in de gateway, of elders.

Verschillend is dat links het functionele blok als applicatie benoemd wordt, en rechts als een API. Dit om duidelijk te maken dat er een verschil zit in functie: de afnemer vraagt om verwerking, de aanbieder verwerkt. Beide zijn echter volwaardige softwarecomponenten waar allerlei functionaliteit ingebouwd kunnen zijn. De API zal soms op een eenvoudig doorgeefluik lijken, en soms gegevens uit verschillende bronnen halen en toegevoegde waarde bieden door te combineren, berekenen, minimaliseren, etc.

Generieke architectuur van een federatief koppelvlak #

In het FDS is de architectuur uitgebreider:

De volgende componenten zijn erbij gekomen:

FTV:

• Toegangsverlening: het onderwerp van deze methodiek, een vorm van bepalen wat inhoudelijk mag qua diensten en gegevens.
• Toegangslog: een log van de genomen toegangsbeslissingen.

FSC:

• Federatieve Service Connectiviteit (FSC), de transactiecomponent in het FDS.
• Transactielog: een log van de transacties op het transportniveau. Dit zijn gegevens zoals tijdstip, certificaat, ip adres van het aanvragend systeem, etc. De inhoud van het bericht zelf wordt hier niet in meegenomen.

LDV:

• Logboek dataverwerkingen: een log op verwerkingenniveau waarin juist wel de inhoud van het bericht centraal staat, en daarbij gegevens zoals de grondslag van de verwerking bewaard blijven.

Deze blokken zijn bewust niet met pijlen verbonden, omdat het aanroepen van toegang en logboek dataverwerkingen zowel kan plaatsvinden vanaf de applicatie als vanaf de gateway.

Generieke architectuur van EAM-toegangsverlening #

Een EAM-oplossing heeft de volgende generieke architectuur:

• Toegangsverlening start als de Policy Enforcement Point (PEP) wordt aangesproken, door de applicatie, API of gateway. Beiden hebben de mogelijkheid om een transactie door te laten gaan of te blokkeren, en daarmee af te dwingen dat de toegangsbeslissing gehonoreerd wordt. In de FDS-architectuur is gekozen om FSC de aanroep te laten doen, door de gateway dus.
• Het Policy Decision Point (PDP) wordt gevraagd om de beslissing te nemen. Daarvoor gebruikt het policies uit de PAP en attributen uit de PIP.
• Het Policy Access Point (PAP) haalt de policies op die geëvalueerd moeten worden. De policies moeten ‘buiten’ de software zijn opgeslagen, op een plek die bereikbaar is voor mensen en systemen van buiten zodat audits gedaan kunnen worden.
• Het Policy Information Point (PIP) haalt op verzoek van de PDP waarden van attributen op. Deze kunnen komen uit:
  1. De vrager, of subject. Dit is de identiteit in brede zin, waaronder ook rollen en verklaringen vallen;
  2. De vraag, of actie. Dit zijn de gekozen dienst of API en de parameters die zijn meegegeven;
  3. Het antwoord, of object. Het kan zijn dat er een eigenschap van de gevraagde data van invloed is op de toegang. Als er bijvoorbeeld gegevens van personen gevraagd worden waar in principe recht op is, maar dat er in de populatie bijzondere personen zitten die afgeschermd zijn.
  4. De context. Dit zijn aller veranderlijke aspecten, zoals tijd, geolocatie, gebruikt apparaat, authenticatiesterkte, eerdere verzoeken, etc.

Federatief EAM #

Dit plaatje toont een federatieve EAM-oplossing, met als extra elementen:

• Beide kanten implementeren EAM. Het is niet noodzakelijk dat ze dezelfde implementatie daarvoor kiezen.
• Beide kanten delen dezelfde toegangsregels. In een federatief stelsel ligt het voor de hand daar een gedistribueerde oplossing voor te kiezen. Dit in tegenstelling tot losse systemen die handmatig synchroon gehouden moeten worden, en ook in tegenstelling tot één enkele database waarbij een enkel kritisch systeem zou ontstaan.