Feedback op implementatiescenario

[BramWithaar]

De tekening en de toelichting lijken te stellen dat een API niet zelf verbind naar een policy Engine om een binnenkomend request te valideren. Het lijkt ons logisch, en zinvol, als een API dat wel zelf kan, en dus ook niet perse afhankelijk is van een (centrale) api gateway. In scenario's met een mix van SaaS en on-premise applicaties kan dat zomaar leiden tot meerdere api gateway's.

Het model lijkt uit te gaan van personen als actor, en niet een systeem als actie. Als dat idd zo is dan staat het bestaande landschap bij gemeenten heel ver af van dit doel; Er zouden dan op zijn minst uitgewerkte (tussen) stappen moeten zijn hoe je hier als gemeente naar toe kunt groeien. Wat daar ook meespeelt is dat, als er al iets gebeurt aan authenticatie, het nu is op basis van mTLS, waarbij systemen zich authenticeren. Systemen die bij aanroepen van api's context over de user die een actie in gang zet kennen we nog niet. Daarnaast zullen er altijd acties zijn die door systemen geïnitieerd worden. Hoe worden de rechten van een systeem gevat in een policy Engine model? De stap van dat (mTLS) model naar dit model is enorm en niet in 1x te zetten.

We denken dat een model met een Policy Engine de toekomst is, maar er is een gelaagder pad nodig (bv eerst een api gateway icm mTLS, dan een eerste stapje naar een PE, dan een of twee api's die obv oAuth ontsloten worden, dan ingewikkelder rules) om er te komen.

[albertpost]

Deze feedback omschrijft heel goed de vragen die wij ook hebben: de mix tussen saas en on premise applicaties met meerdere api gateway’s en de stappen en de route van mTLS naar OAuth.

[wvnoortroxit]

Het diagram in de referentie architectuur lijkt te suggereren dat de API gateway altijd connect naar de Policy engine. In een aantal gevallen kan dat zinvol zijn, maar er zullen ook situaties zijn waar dat niet zal werken. Ik zie vanuit twee kanten praktische bezwaren:

1. De informatie in de API call bevat onvoldoende context om de policy te kunnen evalueren. Het voorbeeld dat gegeven wordt over de vergunningverlener die niet zijn eigen aanvraag mag behandelen is daar een goed voorbeeld van. De API call zal alleen de minimale gegevens bevatten. Om te kunnen beoordelen of aan de policy voldaan wordt is aanvllende data nodig die via de API zal moeten worden opgehaald.
2. Er is een trade-off met de performance eisen. Om voldoende snelle responsetijden te kunnen garanderen kan het nodig zijn om de hoeveelheid processing aan de api-gateway kan te beperken. Zie bijvoorbeeld dit advies uit de NGINX blog: For instance, an e commerce app might grant read only access to product and pricing information to all clients, but allow read write access only to select users. Because of this granularity, authorization is best performed by the backend service that processes the API call itself, because it has the necessary context about the request. With authorization delegated to the business logic layer of the backend, the gateway doesn’t have to perform lookups, resulting in very fast response times. API gateways are certainly capable of performing this function, but you potentially sacrifice real time performance. (https://www.nginx.com/blog/reference-architecture-real-time-apis/)

In het diagram wordt ook (controle van) authenticatie geplaatst in de api-gateway. In veel gevallen zal de client applicatie al de authenticatie hebben gedaan. De meeste web applicaties zullen detecteren dat een gebruiker nog niet is ingelogd en redirecten naar een inlog bij de Identity Provider. De Identity provider genereert dan ee naccesstoken dat vervolgens gebruikt wordt in de call naar de API (via de api-gateway). Het zou goed zijn om die stappen ook te visualiseren in het diagram. Zie bijvoorbeeld het diagram in deze post: https://awskarthik82.medium.com/part-1-securing-aws-api-gateway-using-aws-cognito-oauth2-scopes-410e7fb4a4c0

[meneer]

De tekening en de toelichting lijken te stellen dat een API niet zelf verbind naar een policy Engine om een binnenkomend request te valideren. Het lijkt ons logisch, en zinvol, als een API dat wel zelf kan, en dus ook niet perse afhankelijk is van een (centrale) api gateway. In scenario's met een mix van SaaS en on-premise applicaties kan dat zomaar leiden tot meerdere api gateway's.

Het model lijkt uit te gaan van personen als actor, en niet een systeem als actie. Als dat idd zo is dan staat het bestaande landschap bij gemeenten heel ver af van dit doel; Er zouden dan op zijn minst uitgewerkte (tussen) stappen moeten zijn hoe je hier als gemeente naar toe kunt groeien. Wat daar ook meespeelt is dat, als er al iets gebeurt aan authenticatie, het nu is op basis van mTLS, waarbij systemen zich authenticeren. Systemen die bij aanroepen van api's context over de user die een actie in gang zet kennen we nog niet. Daarnaast zullen er altijd acties zijn die door systemen geïnitieerd worden. Hoe worden de rechten van een systeem gevat in een policy Engine model? De stap van dat (mTLS) model naar dit model is enorm en niet in 1x te zetten.

We denken dat een model met een Policy Engine de toekomst is, maar er is een gelaagder pad nodig (bv eerst een api gateway icm mTLS, dan een eerste stapje naar een PE, dan een of twee api's die obv oAuth ontsloten worden, dan ingewikkelder rules) om er te komen.

Ik denk dat de eerste punten adequaat zijn verduidelijkt in de actuele versie van de referentieplaten. Ik gebruik tegenwoordig de termen access requester en access supplier om te abstraheren van de soort actor, menselijk of niet-menselijk, machine, robot (rpa), webpagina, service. Dat maakt het makkelijker om de policies toe te passen.

Ten aanzien van netwerken en connectiviteit: we moeten onderscheid maken tussen het kanaal waarover communicatie plaatsvindt en de communicatie zelf. In onze optiek is bijv. mTLS prima bruikbaar voor kanaalbeveiling, de 'identiteit' van access point en type verbinding zijn zelf ook weer attributen die in de toegangsbeslissing worden meegenomen. In de communicatie zelf zijn de protocollen leidend. Uitgangspunt is transitie van Platform naar Protocol.

Kenmerk in het gelaagde model: hiërarchie van policy enforcement points en granulariteit van access policies. Beide ook in verbinding met hybride toegansgmodellen (hybride in de zin van webpagina's / portalen die API-requests afvuren en bestaande applicaties die API-requests afvuren.

[meneer]

Deze feedback omschrijft heel goed de vragen die wij ook hebben: de mix tussen saas en on premise applicaties met meerdere api gateway’s en de stappen en de route van mTLS naar OAuth.

Ik verwijs even naar mijn bovenstaande reply, waarin ik ook aangeef dat mTLS en OAuth prima samengaan: mTLS voor de vertrouwde verbinding (in federatie maken we immers afspraken over de verbinding) en Oauth voor de autorisatie-aanvraag. Past mooi op elkaar.

[meneer]

Het diagram in de referentie architectuur lijkt te suggereren dat de API gateway altijd connect naar de Policy engine. In een aantal gevallen kan dat zinvol zijn, maar er zullen ook situaties zijn waar dat niet zal werken. Ik zie vanuit twee kanten praktische bezwaren:

1. De informatie in de API call bevat onvoldoende context om de policy te kunnen evalueren. Het voorbeeld dat gegeven wordt over de vergunningverlener die niet zijn eigen aanvraag mag behandelen is daar een goed voorbeeld van. De API call zal alleen de minimale gegevens bevatten. Om te kunnen beoordelen of aan de policy voldaan wordt is aanvllende data nodig die via de API zal moeten worden opgehaald.

2. Er is een trade-off met de performance eisen. Om voldoende snelle responsetijden te kunnen garanderen kan het nodig zijn om de hoeveelheid processing aan de api-gateway kan te beperken. Zie bijvoorbeeld dit advies uit de NGINX blog:
   For instance, an e commerce app might grant read only access to product and pricing information to all clients, but allow read write access only to select users. Because of this granularity, authorization is best performed by the backend service that processes the API call itself, because it has the necessary context about the request. With authorization delegated to the business logic layer of the backend, the gateway doesn’t have to perform lookups, resulting in very fast response times. API gateways are certainly capable of performing this function, but you potentially sacrifice real time performance.
   (https://www.nginx.com/blog/reference-architecture-real-time-apis/)

In het diagram wordt ook (controle van) authenticatie geplaatst in de api-gateway. In veel gevallen zal de client applicatie al de authenticatie hebben gedaan. De meeste web applicaties zullen detecteren dat een gebruiker nog niet is ingelogd en redirecten naar een inlog bij de Identity Provider. De Identity provider genereert dan ee naccesstoken dat vervolgens gebruikt wordt in de call naar de API (via de api-gateway). Het zou goed zijn om die stappen ook te visualiseren in het diagram. Zie bijvoorbeeld het diagram in deze post: https://awskarthik82.medium.com/part-1-securing-aws-api-gateway-using-aws-cognito-oauth2-scopes-410e7fb4a4c0

Prima opmerkingen die we in de implementatierichtlijnen meenemen, De referentieplaten zijn hoog-over, ze gaan niet in op alle casussen. daarnaast zijn er enkele uitgangspunten gedefinieerd die niet in de platen zin te herkennen: hiërarchie van PEP's: dat wil zeggen dat er gelaagdheid bestaat in de filters. Daarmee voorkomen we dat er duizenden policies door één component moeten worden afgehandeld. Dat levert een performancevoordeel op en betere schaalbaarheid van policymanagement granulariteit van policies: niet elke policy zal even gedetailleerd zijn. En sommige policies kunnen op grond van een andere request, met andere atttributen, tot andere resultaten leiden. Hybride architectuur: dat betekent dat er meer architectuurmodellen denkbaar zijn, machine 2 machine, IdP 2 SP,, IdP - applicatie 2 SP. En daarbij voorzien we ook service meshes door inzet van micro gateways met ook weer een eigen PEP/PDP rol, met wellicht een heel slanke policy. Ook dat levert weer schaalbaarheids- en performancevoordelen op.

Maar we zien wel dat de huidige manier van het ontwikkelen van API's niet uitgaat van deze 3 principes. Dat betekent dat wat ons betreft een transitieperiode niet te voorkomen is. Bestaande silo's zullen aanvullende API's of endpoints moeten krigen.

[BramWithaar]

Deze feedback omschrijft heel goed de vragen die wij ook hebben: de mix tussen saas en on premise applicaties met meerdere api gateway’s en de stappen en de route van mTLS naar OAuth.

Ik verwijs even naar mijn bovenstaande reply, waarin ik ook aangeef dat mTLS en OAuth prima samengaan: mTLS voor de vertrouwde verbinding (in federatie maken we immers afspraken over de verbinding) en Oauth voor de autorisatie-aanvraag. Past mooi op elkaar.

mTLS voor de verbinding snap ik. De opmerking gaat over mTLS voor de authenticatie; ook dat wordt nu veel ingezet en de stap naar oAUTH, hoe terecht dat als doel ook is, is enorm.

[adgerrits]

Is dat zo? oAuth is ondertussen "zo'n standaard standaard" dat je die ook binnen de overheid zou moeten willen toepassen. Sterker nog: daarvoor is het oAuth 2.0 profiel al tot 'ptolu' verklaard (maar m.i. nog incompleet omdat de cliënt credentials flow ontbreekt). Op zijn Cruyffiaans: waar genoeg wil is komt vanzelf een weg.

[eric-nieuwland]

Het diagram in de referentie architectuur lijkt te suggereren dat de API gateway altijd connect naar de Policy engine. In een aantal gevallen kan dat zinvol zijn, maar er zullen ook situaties zijn waar dat niet zal werken. Ik zie vanuit twee kanten praktische bezwaren:

1. De informatie in de API call bevat onvoldoende context om de policy te kunnen evalueren. Het voorbeeld dat gegeven wordt over de vergunningverlener die niet zijn eigen aanvraag mag behandelen is daar een goed voorbeeld van. De API call zal alleen de minimale gegevens bevatten. Om te kunnen beoordelen of aan de policy voldaan wordt is aanvllende data nodig die via de API zal moeten worden opgehaald.

Dit lijkt me niet zozeer een praktisch bezwaar als wel een autorisatievorm die nog niet benoemd is: Content/Context Based Access Control. Die komt pas nadat een gebruiker op basis van attributen toegelaten is tot de dienst die een API levert. Vervolgens moet de API-service op basis van de inhoud van de gegevens en de attributen van de gebruiker beslissen of het die dienst ook kan/mag/wil leveren. Een deel van de informatie die nodig is om tot dit besluit te komen is nog niet eerder in de flow beschikbaar geweest. Dit legt meteen een algemene beperking in het model bloot: er wordt (nog) geen rekening gehouden met autorisatiebeslissingen die genomen moeten worden tijdens de informatieverwerking met gegevens die pas gedurende die verwerking beschikbaar komen. De vraag is ook wie die beslissingen gaat nemen, de dienst of de policy-engine (via de API-gateway).

[adgerrits]

Terechte opmerking dat in de praktijk autorisatiebeslissingen op meerdere plaatsen wenselijk/nodig kunnen zijn. Zoals hierboven al is aangegeven kunnen bepaalde beslissingen (terecht) worden belegd bij bijv. een client-app, API-Gateway, Policy Engine als backend-API. Oftewel: ook hier geldt 'it depends'. Wat mij betreft kan het diagram vooral gezien worden als een (nieuw) type inrichting om autorisatie meer (maar dus niet exclusief) in te kunnen richten via policies (waarvoor ook geldt dat het grote voordelen kan bieden, maar ook niet altijd zaligmakend is...)

[meneer]

Het diagram in de referentie architectuur lijkt te suggereren dat de API gateway altijd connect naar de Policy engine. In een aantal gevallen kan dat zinvol zijn, maar er zullen ook situaties zijn waar dat niet zal werken. Ik zie vanuit twee kanten praktische bezwaren:

1. De informatie in de API call bevat onvoldoende context om de policy te kunnen evalueren. Het voorbeeld dat gegeven wordt over de vergunningverlener die niet zijn eigen aanvraag mag behandelen is daar een goed voorbeeld van. De API call zal alleen de minimale gegevens bevatten. Om te kunnen beoordelen of aan de policy voldaan wordt is aanvllende data nodig die via de API zal moeten worden opgehaald.

Dit lijkt me niet zozeer een praktisch bezwaar als wel een autorisatievorm die nog niet benoemd is: Content/Context Based Access Control. Die komt pas nadat een gebruiker op basis van attributen toegelaten is tot de dienst die een API levert. Vervolgens moet de API-service op basis van de inhoud van de gegevens en de attributen van de gebruiker beslissen of het die dienst ook kan/mag/wil leveren. Een deel van de informatie die nodig is om tot dit besluit te komen is nog niet eerder in de flow beschikbaar geweest. Dit legt meteen een algemene beperking in het model bloot: er wordt (nog) geen rekening gehouden met autorisatiebeslissingen die genomen moeten worden tijdens de informatieverwerking met gegevens die pas gedurende die verwerking beschikbaar komen. De vraag is ook wie die beslissingen gaat nemen, de dienst of de policy-engine (via de API-gateway).

Bedankt voor je reactie. Je brengt enkele terechte opmerking in, maar ik denk dat we die wel in RAWA hebben verwerkt. Waar je het hebt over Context, is dat zonder meer relevant, maar wij beschouwen de Context als een factor die in de policy moet worden meegewogen. De Contextvariable bepaalt immers specifiek of toegang, gegeven de context, toegestaan kan zijn. De policy moet de context gedefinieerd hebben als parameter, anders zal die nooit meegenomen kunnen worden. Daar waar in RBAC gesteld kan worden dat meer rollen ook meer autorisaties oplevert, is de context de toegangbeperkende factor. Maar RBAC kent dat concept niet, vandaar dat ee business rule, een policy moet worden gedefieerd. Dus de PEP moet verkeer altijd langs de PDP/PAP leiden. Verplicht.

Ten aanzien van je tweede punt: er mogen idealiter geen autorisaties binnen de service worden gedefinieerd. Als er, naast de aangeleverde attributen (incl. de context) andere autorisatieregels moeten worden geraadpleegd, dan is daar de PIP de aangewezen construct voor. De service moet, security-wise, dom zijn, alle securitylogica, dus incl. autorisaties, worden buiten de service afgehandeld.

Idealiter. In de proof of architecture bij Den Haag was beide lastig. De OpenZaak API biedt toegang tot legacy services met RBAC in de back-end. Dat hebben we gefixt door een PIP met RBAC rol/functie regels te creëren. Smerig, maar ja, legacy API en legacy applicatie. Daarnaast hebben we de çontext voor OpenZaak (klant/casus) als variabele geïnjecteerd in de field-parameter. Ook smerig, maar ja, zo hebben we we de context bewaard in de procesgang.

Kortom, de refarch is wel goed, maar we hebben op dit moment te maken met heel veel legacy die we achter API's proberen te ontsluiten. RAWA geeft de goede architectuur (uitgaande van ZTA) maar implementatie in het huidige applicatielandschap vergt aanpassingen, zoals bij Den Haag. En dat blijkt te werken en levert daarmee een bijdrage aan de transitie (die, zoals we verwachten 20 jaar zal duren... )

[eric-nieuwland]

Lijkt me inderdaad de zuiverste benadering om alle autorisatiebesluiten door het PDP te laten nemen. Mogelijk is een tweede plaat in "Implementatiescenario RAWA" handig, waarin het verloop ven autorisatieverzoeken vanuit de API-service worden getoond.

Creatieve oplossing, binnen de bestaande beperkingen.

[meneer]

Goed idee. Een keer een whiteboardsessie doen, zien hoe we een en ander toekomstvast en transitiestabiel kunnen vormgeven. Transitiestabiel? Geen idee, maar klinkt wel stoer 😀