Handreiking FTV standaarden
Algemeen
Beheerder: Logius
Status bij Forum Standaardisatie: geen
Waarde van de standaard
De Federatieve Toegangsverlening (FTV) standaarden zijn een bundeling van drie standaarden die bedoeld zijn om het beheren en uitvoeren van autorisaties te ondersteunen:
- NL GOV profile for OpenID AuthZen Authorization API (kortweg AuthZen NL Gov) is een set Nederlandse afspraken over het gebruik van de internationale standaard AuthZen Authorization API. Het beschrijft hoe een autorisatieverzoek naar een autorisatieserver (ook wel: policy enforcement point) op gestandaardiseerde wijze kan worden uitgevoerd.
- Authorization Decision Log (Logboek Toegangsbeslissingen) is een standaard die beschrijft hoe toegangsbeslissingen (ook wel: autorisatiebeslissingen) die zijn genomen moeten worden vastgelegd in een specifiek daarop gericht auditlog.
- Register Toegangsbeleid is een standaard die beschrijft hoe toegangsbeleid (autorisatieregels) moet worden vastgelegd (en kan worden ontsloten) en aan welke eisen een dergelijke opslag moet voldoen.
Belangrijke voordelen van deze FTV standaarden, inclusief de onderliggende standaarden standaarden zijn:
- Faciliteren van een federatieve inrichting van toegangsbeheer, zodat het federatief delen van data beter kan worden ondersteund en partijen deze beter in staat zijn hun eigen verantwoordelijkheid te nemen (datasoevereiniteit).
- Standaardiseren van de aanroep van autorisatieverzoeken, zodat autorisatieservers eenvoudig kunnen worden vervangen door oplossingen van andere leveranciers.
- Externaliseren van het beheer en de uitvoering van autorisaties, zodat deze los van applicaties, op een meer uniforme en daarom beter beheersbare wijze kunnen worden uitgevoerd.
- Inzicht geven in actueel en historisch toegangsbeleid, zodat duidelijk is aan welke eisen afnemers dienen of dienden te voldoen om toegang te krijgen.
- Meer inzicht creëren in autorisatiebeslissingen die zijn genomen en de regels die daaraan ten grondslag liggen, zodat organisaties beter zicht krijgen op afwijkend gedrag en mogelijk misbruik van identiteiten en daarmee meer in control zijn.
De FTV standaarden bieden waarde aan de volgende specifieke doelgroepen:
| Doelgroep | Waarde |
|---|---|
| Management |
|
| Ontwikkelaars |
|
| Functioneel beheerders |
|
Werking van de standaard
De AuthZen NL Gov standaard beschrijft vooral een standaard API voor het uitvoeren van autorisatieverzoeken. Een autorisatieverzoek gaat over wie (subject), wat (actie) met welk object (resource) mag uitvoeren, binnen een bepaalde context (zoals wanneer en waar). Er kunnen daarbij ook verifieerbare verklaringen conform SAML, OAuth of het W3C verifiable credentials datamodel worden gebruikt. Een autorisatieverzoek leidt tot een autorisatiebeslissing. Onderdeel van een autorisatiebeslissing kunnen ook zijn: de motivatie voor de beslissing en/of adviezen of verplichtingen voor de verdere afhandeling. Denk bijvoorbeeld aan het verzoek tot een step-up autorisatie. Autorisatieverzoeken kunnen ook gecombineerd worden in één aanroep. Aanvullend biedt de API ook de mogelijkheid om te zoeken in autorisatieregels. Daarmee is het mogelijk om zowel naar subjecten, acties als resources te zoeken, passend bij een autorisatiecontext. De standaard gaat uit van JSON berichten over HTTPS. In de toekomst kunnen ook andere transportprotocollen kunnen worden toegevoegd.
De Authorization Decision Log beschrijft hoe een opdracht tot het opslaan van een toegangsbeslissing eruit moet zien. Het logboek gebruikt daarom het AuthZEN-gegevensmodel als basis voor de gegevens die moeten worden vastgelegd in de log. Het stelt dat zowel het autorisatieverzoek als het bijbehorende antwoord wordt vastgelegd. Aanvullend kan worden verwezen naar de gehanteerde autorisatieregels, gebruikte informatiebronnen, configuratie-informatie alsook eventuele correlatie-identificaties. De standaard beschrijft alleen de gegevens die moeten worden vastgelegd, maar niet op welke wijze deze worden vastgelegd. Er wordt wel geadviseerd om daarbij gebruik te maken van het OpenTelemetry Protocol. De standaard beschrijft verder dat loginformatie op verschillende detailniveaus kan worden vastgelegd. Het laat het aan organisaties zelf om te bepalen welk detailniveau wordt gekozen.
Het Register Toegangsbeleid is nog in ontwikkeling. Het beoogt vast te leggen aan welke eisen de opslag en ontsluiting van autorisatieregels moet voldoen. Bijvoorbeeld hoe versies van autorisatieregels over tijd bewaard kunnen blijven. Toegangsbeleid kan op verschillende niveaus worden gedefinieerd, van abstracte sjablonen tot concrete regels. Ook wordt vastgelegd welke metadata een autorisatieregel moet en mag hebben.
Relatie met GDI domeinarchitectuur gegevensuitwisseling
De FTV standaarden geven een invulling aan de volgende principes in de domeinarchitectuur.
| Principe | Invulling |
|---|---|
| Gegevens die kunnen worden gedeeld zijn vindbaar, toegankelijk, interoperabel en herbruikbaar | De standaarden maken autorisatieregels die gelden voor het verkrijgen van toegang tot gegevens expliciet |
| Burgers en organisaties hebben regie over hun eigen gegevens | De standaarden bieden organisaties regie doordat autorisatieregels en autorisatiebeslissingen meer inzichtelijk worden en sneller kan worden gestuurd op afwijkend gedrag. |
| Persoonsgegevens zijn beschermd bij het uitwisselen van gegevens | De standaarden faciliteren autorisatie tot gegevens op basis van expliciet vastgelegde autorisatieregels en hun koppeling naar toegangsbeleid |
| Gegevensuitwisseling is federatief georganiseerd | De standaarden maken het mogelijk om het uitvoeren van autorisaties bij zowel aanbieders als afnemers van gegevens te beleggen en daarmee verantwoordelijkheden meer decentraal naar afnemers te verschuiven |
| Voorwaarden en afspraken zijn expliciet en inzichtelijk | De standaarden maken autorisatieregels die gelden voor het verkrijgen van toegang tot gegevens expliciet |
De standaarden zijn ondersteunend aan de volgende functies in het functiemodel van de domeinarchitectuur:
- Verlenen toegang
Positionering van de standaard
Relatie met federatieve datastelsels
In federatieve datastelsels vindt autorisatiebeheer in potentie bij zowel de aanbieders als afnemers van gegevens plaats. Daarbij wordt het mogelijk om een deel van de autorisaties die traditioneel bij de aanbieder liggen, te verschuiven naar de kant van de afnemer. Het gaat daarbij vooral om controles die betrekking hebben op de gebruikers aan de kant van de afnemer. Idealiter heeft de aanbieder geen zicht op de identiteiten van deze gebruikers, maar is er een vertrouwensrelatie tussen beide partijen. De standaarden faciliteren autorisaties zowel op het niveau van organisaties als op het niveau van individuele gebruikers.
In de IDS RAM referentie-architectuur voor dataspaces wordt in dit kader gesproken over usage control. In die architectuur worden verantwoordelijkheden van afnemers voor autorisatiecontrole geborgd in de connector van de afnemer. Connectoren zijn een kernonderdeel van die architectuur en de plaats waar aan de kant van aanbieder en afnemer allerlei functionaliteit zoals controles kunnen worden ingebouwd. Connectoren gebruiken het Dataspace Protocol waarin autorisatiecontroles een aangewezen plaats hebben.
Relatie met auditlogs
Een auditlog is primair gericht op het vastleggen van gebeurtenissen die relevant zijn vanuit het perspectief van informatiebeveiliging. Dat zijn naast fouten en uitzonderingen vooral gevoelige handelingen die zijn uitgevoerd door gebruikers, beheerders of informatiesystemen. Het Authorization Decision Log is te zien als een specifieke manifestatie van een auditlog. Er worden echter meer specifieke eisen gesteld aan deze log, zodat de kans groot is dat het als een aparte log zal moeten worden gerealiseerd.
Impact van de standaard
De FTV standaarden ondersteunen Policy Based Access Control (PBAC). Dit is een architectuur waarbij de autorisatieregels (policies) centraal staan. De architectuur is op hoofdlijnen in de volgende figuur weergegeven. De autorisatieregels worden beheerd in een Policy Administration Point (PAP). Ze worden gebruikt in een Policy Decision Point (PDP) die ze interpreteert om er een autorisatiebeslissing op te baseren. Deze beslissing wordt afgedwongen in een Policy Enforcement Point (PEP) naar aanleiding van een verzoek dat wordt gesteld door een systeem. Het Policy Information Point (PIP) stelt hiervoor relevante contextgegevens beschikbaar. Naast een autorisatiebeslissing levert het PDP ook verplichtingen (obligations) op, die leiden tot specifieke acties die randvoorwaardelijk zijn om toegang te kunnen krijgen.

Figuur 1: De PxP architectuur
De standaarden stellen eisen aan verschillende componenten in deze architectuur. Zo vraagt AuthZen de implementatie van de authorization API in een PDP, maar bijvoorbeeld ook het op verzoek kunnen leveren van een standaard set van metagegevens. Er moet een vertrouwensrelatie zijn tussen de PEP en de PDP en de PDP moet de PEP authenticeren. De Authorization Decision Log zou ook moeten worden geïmplementeerd door de PDP. Het Register Toegangsbeleid stelt vooral eisen aan de PAP. Tegelijkertijd vraagt het dat er een koppelvlak is tussen de PAP en de PDP om de autorisatieregels te synchroniseren. Een logregel zou ook moeten verwijzen naar de gebruikte autorisatieregels.
Er is een referentie-implementatie van de FTV standaarden in de vorm van OpenFTV. Deze is op dit moment nog niet bedoeld voor productiedoeleinden. Het biedt referentie-implementaties van een PAP, PDP en PIP. Het PDP ondersteunt een aantal autorisatieservers en talen: OPA/Rego, cedar, Cerbos en OpenFGA.
Zoals aangegeven kan er in de context van datastelsels voor worden gekozen om het beheer en de uitvoering van autorisaties zowel bij aanbieders en afnemers te beleggen. Dat betekent dat bovenstaande architectuur ook bij afnemers wordt geïmplementeerd. Als gebruik wordt gemaakt van het Dataspace Protocol dan ligt die verantwoordelijkheid bij de connectoren. Als gebruik wordt gemaakt van de FSC standaard dan zullen de inway en de outway componenten functioneren als PEP en de autorisatieverzoeken moeten sturen naar een PDP (autorisatieserver). In de OpenFSC referentie-implementatie van de FSC standaard is de AuthZen standaard inmiddels ingebouwd.
Aandachtspunten
Semantische standaardisatie
De standaard is generiek opgezet en heeft geen kennis van de soorten acties en objecten in specifieke toepassingscontexten. Dat betekent dat er alleen technisch gestandaardiseerd is en dat er dus veel wordt opengelaten om te standaardiseren in specifieke contexten. De standaard zegt ook niets over het soort regels dat typisch waardevol is om uit te drukken. Het zou waardevol zijn om dat verder te standaardiseren. Het zou meer duidelijkheid creëren tussen partijen over de voorwaarden en afspraken die gelden bij gegevensuitwisseling.
Relatie met andere standaarden
Relatie met Logboek Dataverwerkingen
Logboek Dataverwerkingen beschrijft hoe overheden gegevens kunnen vastleggen over hun verwerkingen om daarmee verantwoording te kunnen afleggen. Een autorisatie kun je beschouwen als een verwerking dus zou in potentie in een dergelijk logboek vastgelegd kunnen worden. Gebeurtenissen gerelateerd aan informatiebeveiliging zouden echter primair in een auditlog moeten vastgelegd. Het Register Toegangsbeleid is een specifieke manifestatie van een auditlog. De standaard adviseert om gebruik te maken van het OpenTelemetry Protocol, dat ook gebruikt wordt in het Logboek Dataverwerkingen. Onderdeel daarvan is het vastleggen van de correlatie-identifiers (trace_id en span_id) die ook in Logboek Dataverwerkingen worden gebruikt. Hierdoor zijn de verschillende logfiles aan elkaar te correleren.
Relatie met FSC
Federated Service Connectivity (FSC) is een standaard die is gericht op eenvoudig, veilig en beheersbaar gebruik van API’s. De standaard biedt een extensie voor logging. Daarmee is het mogelijk om de verzending en ontvangst van berichten te loggen. Daarbij wordt gebruik gemaakt van een gemeenschappelijke transactie-identificatie, zodat achteraf inzicht in kan worden gegeven in hun samenhang. In het Logboek Toegangsbeslissingen is de aansluiting bij de FSC logging beschreven. In het bijzonder is aangegeven dat de transactie-identificatie van FSC onderdeel zou moeten uitmaken van de logging van toegangsbeslissingen.
Links
11 mei 2026 08:57:28
11 maart 2026 07:17:34
11 mei 2026 08:57:28
5
Informatief