Werken met API's informatiearchitectuur
Goed kunnen werken met API's vereist een informatiearchitectuur die hiervoor geschikt is. Binnen de thema-architectuur Werken met API's is als eerste aandacht besteed aan het vraagstuk hoe toegang gebruik van niet-openbaar toegankelijke API's verantwoord kan plaatsvinden. Daarvoor moet eerst worden vastgesteld wie of wat toegang zoekt zodat bekend is om welke 'identiteit' het gaat. Daarna moet worden beslist of deze identiteit bevoegd is om (en eventueel hoe) een bepaalde API te gebruiken.
Identiteit en Toegangbeheer beschrijft hoe Identiteitenbeheer en Toegangsbeheer zich tot elkaar verhouden. Daarbij is aangegeven dat het wenselijk is dat toegangsbeheer zich vanuit een 'ieder-voor-zich inrichting' ontwikkelt naar een inrichting die is gebaseerd op gedefinieerde en afdwingbare bedrijfsregels. Naast bekende autorisatiemechanismen zoals Role- en Attribute Based Access Control (RBAC en ABAC) wordt ook vaker Policy Based Access Control (PBAC) nodig. Voor een toelichting op deze mechanismen zie 'RBAC ABAC en PBAC toegangscontrole'.
Het onderstaande architectuurdiagram beschrijft een in de praktijk vaak voorkomende situatie waarin een door eindgebruikers gebruikte cliënt-applicatie gebruik wil maken van een door een andere applicatie aangeboden API. Het diagram is bedoeld om te tonen hoe daarbij van PBAC gebruik is te maken zodat beslissingen over API-toegang op basis van gedefinieerde bedrijfsregels ('policies') zijn te nemen.
Voor het binnen het diagram weergegeven patroon geldt uiteraard dat er in de praktijk tal van variaties mogelijk zijn. Bepaalde autorisatiebeslissingen kunnen bijvoorbeeld om een bepaalde reden op een andere plaats worden belegd of sommige van de afgebeelde applicatiecomponenten spelen in bepaalde situaties geen rol.
Infomatiearchitectuur voor PBAC globaal[bewerken]
Onderstaand globaal architectuurmodel toont een informatiearchitectuur met componenten die betrokken zijn bij het gebruik van Policy Based Access Control.
Toelichting op de weergegeven globale flow:
- De Cliënt-applicatie doet namens de gebruiker een verzoek waarbij toegang tot een API nodig is.
- De API Gateway die het verzoek ontvangt vraagt bij een Identity Provider authenticatiegegevens van gebruiker en/of client-applicatie op.
- De API Gateway beslist op basis van de ontvangen authenticatiegegevens of (vooralsnog) API-aanroep is toegestaan.
- Als toegang (vooralsnog) is toegestaan worden verzoek- en authenticatie-gegevens doorgegeven aan een Policy Engine die met gebruik van vastgelegde regels toetst of API-aanroep moet worden toegestaan.
- De API Gateway beslist op basis van de ontvangen toetsresultaten of API-aanroep is toegestaan.
- Als toegang (definitief) is toegestaan wordt de API aangeroepen (met doorgave van verzoek en eventueel authenticatiegegevens).
- De API Gateway ontvangt antwoord van de API.
- De API Gateway geeft het ontvangen antwoord terug aan de Cliënt-applicatie.
Referentiecomponenten[bewerken]
De GEMMA kent ‘referentiecomponenten’: “een modulair, zelfstandig inzetbaar en vervangbaar deel van een systeem, dat zijn functionaliteit aanbiedt via goed gedefinieerde interfaces. Applicatiecomponenten stellen een functionaliteit beschikbaar, die gebruikt wordt om de applicatiediensten mee te leveren”. In het weergegeven model spelen een viertal referentiecomponenten een rol:
- Identity provider. Binnen de GEMMA aangeduid als 'Gebruikersbeheercomponent': een component voor de opslag en ontsluiting van identiteiten van gebruikers en de rechten die zij hebben. Voorbeelden van producten voor identity providing zijn: Azure AD, Keycloak, Okta en Auth0.
- API gateway - Een toegangspunt voor API's dat verzoekverwerking uitvoert op basis van gedefinieerd beleid inclusief authenticatie, autorisatie, toegangscontrole, SSL/TLS-offloading, routering en load balancing. Voorbeelden van API Gateway producten zijn Kong en NGINX. Cloud providers leveren (ook) eigen producten zoals AWS API Gateway, Google Cloud API Gateway en Azure API Management.
- Policy Engine - Een component die op basis van vastgelegde regels beoordeelt of een verzoek voldoet aan een gedefinieerd toegangsbeleid. Voorbeelden van producten zijn Open Policy Agent, Axiomatics en PlainID. Een Policy engine bevat meestal 2 deel-componenten (die theoretisch ook als aparte component kunnen functioneren):
- Policy Decision Point (PDP) - de component die de beoordeling uitvoert.
- Policy Administration Point (PAP - de component waarmee bij de beoordeling te gebruiken bedrijfsregels worden onderhouden.
Infomatiearchitectuur voor PBAC gedetailleerd[bewerken]
Onderstaand architectuurmodel toont de informatiearchitectuur voor gebruik van Policy Based Access Control meer in detail.
Ten opzicht van het eerdere globale diagram is in bovenstaand diagram aangegeven:
- Welke (applicatie) services worden gerealiseerd door de verschillende componenten.
- Dat een Policy Engine niet alleen gebruik hoeft te maken van 'eigen' bedrijfsregels, maar ook relevante data uit externe bronnen kan opvragen.
- Dat componenten bepaalde 'services' leveren die samen zorgen voor het uitvoeren van PBAC:
- een Policy Engine fungeert als Policy Decision Point door op basis van bedrijfsregels te beslissen of een verzoek mag worden ingewilligd.
- een Policy Enging fungeert als Policy Administration Point door het beheer van lokaal vastgelegde bedrijfsregels te faciliteren.
- een externe applicatie kan fungeren als Policy Information Point door een bepaald type data beschikbaar te stellen voor gebruik door een Policy Engine.
- een API Gateway fungeert als Policy Decision Point door op basis van alle vergaarde informatie te besluiten of een verzoek om een API te benaderen zal worden toegestaan.