Autorisatie via toegangsbeheer

Autorisatie is het proces van het verlenen van toegang tot de verschillende onderdelen en assets van de webapplicatie aan gebruikers. Een veelgebruikte manier om gebruikers te autoriseren is via toegangsbeheer, waarbij de sitebeheerder bepaalt welke rechten moeten worden verleend aan gebruikers en andere entiteiten om toegang te krijgen tot bepaalde bronnen.

Autorisatie moet niet worden verward met authenticatie, wat het proces is van het valideren dat de gebruiker is wie hij of zij beweert te zijn, doorgaans gerealiseerd door het opgeven van inloggegevens. Zodra de gebruiker is geverifieerd, moet het autorisatieproces nog steeds bij elk verzoek worden uitgevoerd, om te verzekeren dat de gebruiker toegang heeft tot de gevraagde bron.

Bij toegang tot de applicatie via GraphQL moeten we controleren of de gebruiker toegang heeft tot de gevraagde elementen van het schema. Moet de autorisatielogica worden gecodeerd in de GraphQL-laag?

Het antwoord is nee. Zoals de documentatie op graphql.org duidelijk maakt, behoort de autorisatielogica tot de bedrijfslogicalaag, en van daaruit wordt deze benaderd door GraphQL. Op deze manier kan de applicatie één enkele bron van waarheid hebben voor autorisatie (namelijk die van WordPress):

Gato GraphQL respecteert dit principe en weerspiegelt (en delegeert onder de motorkap naar) het autorisatiemechanisme van WordPress.

​

Toegangsbeheerbeleidsregels

Van de verschillende toegangsbeheerbeleidsregels die we voor onze applicatie kunnen implementeren, zijn de twee populairste Role-Based Access Control (RBAC) en Attribute-Based Access Control (ABAC).

WordPress, en Gato GraphQL, ondersteunen beide.

Met Role-Based Access Control verlenen we rechten op basis van rollen en wijzen we de rollen vervolgens toe aan gebruikers. WordPress heeft bijvoorbeeld een administrator-rol met toegang tot alle bronnen, en rollen editor, author, contributor en subscriber met beperkte rechten in verschillende mate, zoals de mogelijkheid om een blogbericht te maken en publiceren, alleen te maken, of alleen te lezen.

Met Attribute-Based Access Control worden rechten verleend op basis van metadata die aan verschillende entiteiten kan worden toegewezen, waaronder gebruikers, assets en omgevingscondities (zoals het tijdstip van de dag of het IP-adres van de bezoeker). In WordPress wordt bijvoorbeeld de capability edit_others_posts gebruikt om te valideren of de gebruiker berichten van andere gebruikers kan bewerken.

Over het algemeen is ABAC te verkiezen boven RBAC omdat het ons in staat stelt rechten met fijnmazige controle te configureren, en de toestemming is ondubbelzinnig in zijn doel.

In WordPress heeft de editor-rol bijvoorbeeld de capability edit_others_posts, maar we willen misschien iemand met de author-rol toestaan het bericht van een andere auteur te bewerken, zonder hem of haar de volledige set rechten te geven die aan een editor worden verleend (zoals ook het verwijderen van berichten van andere auteurs). Daarom is het verlenen van de capability edit_others_posts en het controleren op deze voorwaarde meer adequaat dan controleren op de rol editor.

​

De zichtbaarheid bepalen

Wanneer de gebruiker niet over de toestemming beschikt om het gevraagde veld van het GraphQL-schema te benaderen, welke fout moet er dan worden teruggegeven?

Er zijn twee mogelijkheden, in overeenstemming met de gewenste zichtbaarheid voor het schema: publiek of privé.

Voor het publieke schema is het blootgestelde GraphQL-schema hetzelfde voor alle gebruikers, en elk veld beschrijft welke rechten nodig zijn om het te benaderen. Bij het opvragen van een ontoegankelijk veld zal de foutmelding uitleggen waarom de gebruiker geen toegang wordt verleend.

Voor het privéschema is het GraphQL-schema aangepast aan elke gebruiker en worden alleen de velden weergegeven waartoe hij/zij toegang heeft. Bij het opvragen van een ontoegankelijk veld zal de foutmelding vermelden dat het veld niet bestaat.

​

Toegangsbeheer via de gebruikersinterface

In Gato GraphQL worden de toegangsbeheerregels tijdens de uitvoering in het schema geïnjecteerd, als door de gebruiker gedefinieerde configuratie via toegangsbeheerlijsten. Op deze manier weerspiegelt de GraphQL-laag onmiddellijk de wijzigingen in het toegangsbeheerbeleid, zonder dat code hoeft te worden bijgewerkt of het schema opnieuw hoeft te worden gecompileerd:

De sitebeheerder configureert de ACL en selecteert:

• De te valideren velden
• Een te valideren regel, uit:
  • moet de gebruiker ingelogd zijn?
  • moet de gebruiker uitgelogd zijn?
  • moet de gebruiker een bepaalde rol hebben?
  • moet de gebruiker een bepaalde capability hebben?
• De regelspecifieke configuratie:
  • welke rollen?
  • welke capabilities?
• De zichtbaarheid:
  • standaard (d.w.z. dezelfde als toegewezen aan het schema)?
  • publiek?
  • privé?