RBAC in de praktijk: Implementatie van veilige autorisatie voor je applicatie

Heb je moeite met het implementeren van een veilig en schaalbaar autorisatiesysteem voor je applicatie? Role-Based Access Control (RBAC) is de industriestandaard voor het beheren van gebruikersrechten, maar het correct implementeren kan een uitdaging zijn. Deze tutorial laat je zien hoe je een robuust RBAC-systeem kunt bouwen met een voorbeeld van een Content Management System (CMS).

Door deze gids te volgen, leer je:

• ✨ Hoe je fijnmazige permissies ontwerpt en implementeert die je precieze controle geven.
• 🔒 Best practices om permissies te organiseren in betekenisvolle rollen.
• 👤 Technieken voor het effectief omgaan met het eigenaarschap van bronnen.
• 🚀 Manieren om je autorisatiesysteem schaalbaar en onderhoudbaar te maken.
• 💡 Praktische implementatie aan de hand van een CMS-voorbeeld uit de praktijk.

De complete broncode voor deze tutorial is beschikbaar op GitHub.

De basisprincipes van RBAC begrijpen#

Role-Based Access Control gaat verder dan alleen het toewijzen van permissies aan gebruikers. Het gaat om het creëren van een gestructureerde benadering van autorisatie die veiligheid en onderhoudbaarheid in balans houdt.

Je kunt meer leren over Wat is RBAC in de Auth Wiki.

Hier zijn de belangrijkste principes die we in onze implementatie zullen volgen:

Fijnmazig permissieontwerp#

Fijnmazige permissies geven je nauwkeurige controle over wat gebruikers in je systeem kunnen doen. In plaats van brede toegangs­niveaus zoals "admin" of "gebruiker", definiëren we specifieke acties die gebruikers op bronnen kunnen uitvoeren. Bijvoorbeeld:

• read:articles - Bekijk elk artikel in het systeem
• create:articles - Maak nieuwe artikelen
• update:articles - Wijzig bestaande artikelen
• publish:articles - Verander de publicatiestatus van artikelen

Eigenaarschap van bronnen en toegangscontrole#

Eigenaarschap van bronnen is een fundamenteel concept in het autorisatieontwerp van ons CMS. Terwijl RBAC definieert welke acties verschillende rollen kunnen uitvoeren, voegt eigenaarschap een persoonlijke dimensie toe aan toegangscontrole:

• Auteurs hebben automatisch toegang tot artikelen die ze hebben gemaakt
• Dit natuurlijke eigendomsmodel betekent dat auteurs altijd hun eigen inhoud kunnen bekijken en bewerken
• Het systeem controleert zowel rol­permissies OF eigenaarschap bij het verwerken van artikel­handelingen
• Bijvoorbeeld, zelfs zonder de update:articles permissie, kan een auteur nog steeds hun eigen artikelen bewerken
• Dit ontwerp vermindert de behoefte aan extra rol­permissies terwijl de veiligheid behouden blijft

Deze tweelaagse benadering (rollen + eigenaarschap) creëert een intuïtiever en veiliger systeem. Uitgevers en admins kunnen nog steeds alle inhoud beheren via hun rolpermissies, terwijl auteurs controle over hun eigen werk behouden.

Een veilig API-ontwerp maken#

Laten we beginnen met het ontwerpen van de kernfunctionaliteit van ons CMS via zijn API-eindpunten:

Implementeer toegangscontrole voor je API#

Voor elk eindpunt moeten we twee aspecten van toegangscontrole overwegen:

1. Eigenaarschap van bronnen - Behoort de bron toe aan de gebruiker?
2. Rolgebaseerde permissies - Staat de rol van de gebruiker deze bewerking toe?

Hier is hoe we toegang voor elk eindpunt zullen behandelen:

Een schaalbaar permissiesysteem creëren#

Op basis van onze API-toegangsvereisten kunnen we deze permissies definiëren:

Let op dat deze permissies alleen nodig zijn bij het benaderen van bronnen die je niet bezit. Artikel­eigenaren kunnen automatisch:

• Hun eigen artikelen bekijken (geen read:articles nodig)
• Hun eigen artikelen bewerken (geen update:articles nodig)
• Hun eigen artikelen verwijderen (geen delete:articles nodig)

Effectieve rollen bouwen#

Nu we onze API en permissies hebben gedefinieerd, kunnen we rollen creëren die deze permissies logisch groeperen:

Opmerking: Auteurs hebben automatisch lees-/update-/verwijder­permissies voor hun eigen artikelen, ongeacht rol­permissies.

Elke rol is ontworpen met specifieke verantwoordelijkheden in gedachten:

• Admin: Heeft volledige controle over het CMS, inclusief alle artikel­operaties
• Uitgever: Richt zich op het beoordelen en beheer van publicaties
• Auteur: Gespecialiseerd in het creëren van inhoud

Deze rolstructuur creëert een duidelijke scheiding van taken:

• Auteurs richten zich op het creëren van content
• Uitgevers beheren de kwaliteit en zichtbaarheid van de content
• Admins behouden algemene systeemcontrole

RBAC configureren in Logto#

Voordat je begint, moet je een account aanmaken in Logto Cloud, of je kunt ook een zelf-gehoste Logto-instantie gebruiken met behulp van de Logto OSS versie.

Maar voor deze tutorial zullen we Logto Cloud gebruiken voor eenvoud.

Je applicatie instellen#

1. Ga naar "Applicaties" in Logto Console om een nieuwe react-applicatie aan te maken
   • Applicatie naam: Content Management System
   • Applicatietype: Traditionele Web Applicatie
   • Redirect URI's: http://localhost:5173/callback

API-bronnen en rechten configureren#

1. Ga naar "API-bronnen" in Logto Console om een nieuwe API-bron te creëren
   • API naam: CMS API
   • API identificatie: https://api.cms.com
   • Voeg rechten toe aan de API-bron
     • list:articles
     • read:articles
     • create:articles
     • update:articles
     • publish:articles
     • delete:articles

Rollen creëren#

Ga naar Rollen in Logto Console om de volgende rollen voor de CMS te maken

• Admin
  • met alle rechten
• Uitgever
  • met read:articles, list:articles, publish:articles
• Auteur
  • met create:articles

Rollen toewijzen aan gebruikers#

Ga naar het "Gebruikersbeheer"-gedeelte in Logto Console om gebruikers aan te maken.

In het "Rollen"-tabblad van de gebruikersdetails kun je rollen aan de gebruiker toewijzen.

In ons voorbeeld maken we 3 gebruikers met de volgende rollen:

• Alex: Admin
• Bob: Uitgever
• Charlie: Auteur

Integreer je frontend met Logto RBAC#

Nu we RBAC in Logto hebben opgezet, kunnen we beginnen met het integreren ervan in onze frontend.

Volg eerst de Logto Quick Starts om Logto in je applicatie te integreren.

In ons voorbeeld gebruiken we React voor demonstratie.

Nadat je Logto in je applicatie hebt opgezet, moeten we de RBAC-configuraties toevoegen, zodat Logto werkt.

Vergeet niet uit te loggen en opnieuw in te loggen om deze wijziging van kracht te laten worden als je al bent ingelogd.

Wanneer de gebruiker inlogt met Logto en een toegangstoken aanvraagt voor de bovengenoemde API-bronnen, voegt Logto scopes (permissies) gerelateerd aan de rol van de gebruiker toe aan het toegangstoken.

Je kunt getAccessTokenClaims van de useLogto-hook gebruiken om de scopes van het toegangstoken te verkrijgen.

En je kunt de userScopes gebruiken om te controleren of de gebruiker de toestemming heeft om toegang te verkrijgen tot de bron.

Integreer je backend met Logto RBAC#

Nu is het tijd om Logto RBAC in je backend te integreren.

Backend autorisatie-middleware#

Eerst moeten we een middleware toevoegen aan de backend om gebruikers­permissies te controleren, verifiëren of de gebruiker is ingelogd en of ze de nodige permissies hebben om toegang te krijgen tot bepaalde API's.

Zoals je kunt zien, verifiëren we in deze middleware of de frontendrequest een geldig toegangstoken bevat en of de audience van het toegangstoken overeenkomt met de API-bron die we in de Logto Console hebben gemaakt.

De reden voor het verifiëren van de API-bron is dat onze API-bron eigenlijk de bronnen van onze CMS-backend vertegenwoordigt, en al onze CMS-permissies zijn gekoppeld aan deze API-bron.

Aangezien deze API-bron de CMS-bronnen in Logto vertegenwoordigt, voegen we in onze frontendcode het overeenkomstige toegangstoken toe bij het maken van API-verzoeken naar de backend:

Nu kunnen we de requireAuth middleware gebruiken om onze API-eindpunten te beveiligen.

API-eindpunten beveiligen#

Voor API's die alleen toegankelijk moeten zijn voor gebruikers met specifieke permissies, kunnen we direct beperkingen toevoegen in de middleware. Bijvoorbeeld, de API voor het aanmaken van artikelen moet alleen toegankelijk zijn voor gebruikers met de create:articles permissie:

Voor API's die zowel permissies als eigenaarschap van bronnen moeten controleren, kunnen we de functie hasScopes gebruiken. Bijvoorbeeld, in de API voor het opsommen van artikelen, kunnen gebruikers met de list:articles permissie toegang krijgen tot alle artikelen, terwijl auteurs toegang hebben tot hun eigen gemaakte artikelen:

Op dit punt hebben we de RBAC-implementatie voltooid. Je kunt de complete broncode bekijken om de volledige implementatie te zien.

Test de CMS RBAC-implementatie#

Laten we nu onze CMS RBAC-implementatie testen met behulp van de drie gebruikers die we zojuist hebben aangemaakt.

Laten we eerst inloggen als Alex en Charles en wat artikelen aanmaken.

Aangezien Alex de Admin-rol heeft, kan hij artikelen aanmaken, verwijderen, bijwerken, publiceren en alle artikelen bekijken.

Charles, met de rol van Auteur, kan alleen zijn eigen artikelen maken en kan alleen artikelen die hij bezit bekijken, bijwerken en verwijderen.

Bob, met de rol van Uitgever, kan alle artikelen bekijken en publiceren, maar kan ze niet aanmaken, bijwerken of verwijderen.

Conclusie#

Gefeliciteerd! Je hebt geleerd hoe je een robuust RBAC-systeem in je applicatie kunt implementeren.

Voor complexere scenario's, zoals het bouwen van multi-tenant applicaties, biedt Logto uitgebreide organisatiesupport. Bekijk onze gids Bouw een multi-tenant SaaS applicatie: Een volledige gids van ontwerp tot implementatie om meer te leren over organisatiebrede toegangscontrole implementeren.

Veel programmeerplezier! 🚀