Beheersing van RBAC in Logto: Een uitgebreid praktijkvoorbeeld

Inleiding#

Toegangscontrole en beveiliging zijn essentiële aspecten van moderne applicaties, zodat gebruikers passende toegang hebben tot middelen. Logto's Role-Based Access Control (RBAC) biedt ontwikkelaars een efficiënte manier om toegangscontrole en beveiliging in hun applicaties te beheren. In dit artikel verkennen we de krachtige functies van Logto's RBAC-implementatie met behulp van een praktijkvoorbeeld, zodat je deze concepten kunt begrijpen en toepassen op je projecten.

Door zowel front-end als back-end codevoorbeelden te bekijken, krijg je een uitgebreid perspectief op het integreren van Logto's RBAC in je applicatiestack. Aan het einde van dit artikel ben je goed uitgerust om de RBAC-functies van Logto te benutten om de veiligheid en toegangscontrole van je project te verbeteren.

Introductie van BookHarber: Een voorbeeld van een online boekwinkel#

Om de RBAC-functies van Logto effectief te demonstreren, gebruiken we een praktijkvoorbeeld: BookHarber, een online boekwinkel. BookHarber biedt een breed scala aan functies voor klanten en personeel, en zorgt voor een naadloze en veilige winkelervaring.

Belangrijke functies van BookHarber zijn:

1. Bladeren en Boeken Kopen: Gebruikers kunnen eenvoudig zoeken en boeken kopen uit een diverse collectie, die verschillende genres en auteurs beslaat.
2. Bestelbeheer en Logistieke Volgtracking: Geregistreerde klanten kunnen hun bestellingen beheren, verzending volgen en updates ontvangen over hun aankopen.
3. Speciale Aanbiedingen en Vakantieactiviteiten: BookHarber biedt exclusieve kortingen en promoties tijdens speciale evenementen en feestdagen om zijn klantenkring bezig te houden en te belonen.
4. Klantenservice: Klanten kunnen ondersteuningsverzoeken openen om eventuele zorgen of problemen die ze tegenkomen aan te pakken en snel hulp te ontvangen van BookHarber-medewerkers.
5. Klantenbeheer: Personeelsleden met verschillende rollen hebben de mogelijkheid om verschillende aspecten van het platform te beheren, zoals klantenaccounts, orderverwerking en probleemoplossing.

Rollen#

In het BookHarber-ecosysteem kunnen we verschillende belangrijke gebruikersrollen identificeren, zoals:

1. Gast: Niet-geregistreerde gebruikers die de website kunnen bekijken, zoeken naar boeken en speciale aanbiedingen kunnen bekijken.
2. Klant: Geregistreerde gebruikers die boeken kunnen kopen, bestellingen kunnen beheren, logistiek kunnen volgen en ondersteuningsverzoeken kunnen openen.
3. Winkelbeheerder: Medewerkers verantwoordelijk voor het toezicht op het algehele beheer en de werking van het platform. Met volledige toegang.
4. Boekenmanager: Medewerkers verantwoordelijk voor het beheer van boeken en categorieën.
5. Klantenservice Medewerker: Medewerkers belast met het reageren op ondersteuningsverzoeken.
6. Externe Logistieke Leverancier: Externe partners verantwoordelijk voor het beheren en volgen van de verzending en levering van bestellingen.
7. Marketingpersoneel: Medewerkers verantwoordelijk voor de promotie van BookHarber, verantwoordelijk voor het beheren van speciale aanbiedingen en evenementen.

Ontwerpen van scopes voor BookHarber REST API's#

Om Logto's RBAC-systeem voor BookHarber effectief te implementeren, moeten we scopes ontwerpen die overeenkomen met de verschillende REST API's. Scopes zijn rechten die het toegangslevel definiëren dat een specifieke rol heeft voor elk API-eindpunt. Door de juiste scopes aan elke gebruikersrol toe te wijzen, kunnen we ervoor zorgen dat gebruikers alleen toegang hebben tot de acties en middelen die relevant zijn voor hun rol.

Laten we scopes ontwerpen voor de volgende REST API's:

1. Categorieën API:
   • create:categories: POST /categories
   • write:categories: PUT /categories/:id
   • delete:categories: DELETE /categories/:id
   • list:categories: GET /categories
2. Boeken API:
   • create:books: POST /books
   • write:books: PUT /books/:id
   • delete:books: DELETE /books/:id
   • list:books: GET /books
   • read:books: GET /books/:id
3. Klanten API:
   • list:customers: GET /customers
   • write:customers: PUT /customers/:id
   • delete:customers: DELETE /customers/:id
   • read:customers: GET /customers/:id
4. Bestellingen API:
   • create:orders: POST /orders
   • list:orders: GET /orders
   • read:orders: GET /orders/:id
   • write:orders: PUT /orders/:id
5. Evenementen API:
   • create:events: POST /events
   • write:events: PUT /events/:id
   • list:events: GET /events
   • delete:events: DELETE /events/:id
6. Ordertracering API:
   • read:orderTracks: GET /orders/:id/tracks
   • create:orderTracks: POST /orders/:id/tracks
   • write:orderTracks: PUT /orders/:id/tracks/:trackId
7. Tickets API:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

Toewijzen van scopes aan rollen#

Nu we de juiste scopes voor elke REST API hebben gedefinieerd, kunnen we deze scopes toewijzen aan de respectievelijke gebruikersrollen in het BookHarber-ecosysteem:

Begrijp de verschillen tussen "list" en "read" scopes#

Om de verschillen tussen "list" en "read" scopes in de context van REST API design en RBAC verder toe te lichten, laten we een praktijkvoorbeeld bekijken dat betrekking heeft op een online boekwinkel, BookHarber.

Stel dat BookHarber twee soorten gebruikers heeft: klanten en klantenservicemedewerkers. Klanten kunnen bestellingen aanmaken, terwijl klantenservicemedewerkers verantwoordelijk zijn voor het helpen van klanten met hun bestellingen. Laten we eens kijken hoe "list" en "read" scopes van toepassing zijn op de orders API-resource in dit scenario.

1. List Scopes: Een "list" scope stelt de gebruiker in staat om toegang te krijgen tot een verzameling entiteiten in het systeem. Bijvoorbeeld, de list:orders scope staat een gebruiker toe om een lijst van alle beschikbare bestellingen op te vragen. In de context van BookHarber kan deze scope nuttig zijn voor winkelbeheerders of andere medewerkers die een overzicht moeten hebben van alle bestellingen in het systeem. Echter, klantenservicemedewerkers zouden niet in staat moeten zijn om toegang te krijgen tot de volledige lijst van bestellingen, omdat hun rol zich richt op het helpen van individuele klanten met hun specifieke bestellingen.
2. Read Scopes: Een "read" scope verleent de gebruiker toestemming om toegang te krijgen tot een enkele entiteit met een bepaald ID. Bijvoorbeeld, de read:orders scope stelt de gebruiker in staat om gedetailleerde informatie over een specifieke bestelling te bekijken met behulp van het ID. In het geval van BookHarber is deze scope ideaal voor klantenservicemedewerkers die informatie nodig hebben over de bestelling van een specifieke klant. Wanneer een klant een ondersteuningsverzoek opent, kan de klantenservicemedewerker het bestel-ID uit het verzoek gebruiken om toegang te krijgen tot en inzicht te krijgen in de details van die specifieke bestelling.

Begrijp eigenaarschap: Waarom klanten geen "read" of "list" scopes nodig hebben voor hun eigen bestellingen#

In veel applicaties is het gebruikelijk dat gebruikers toegang hebben tot hun eigen middelen zonder dat ze expliciet de bijbehorende "read" of "list" scopes toegekend krijgen. Dit komt doordat gebruikers als eigenaren van deze middelen worden beschouwd en er op natuurlijke wijze toegang toe zouden moeten hebben. In het geval van ons BookHarber voorbeeld kunnen klanten bestellingen aanmaken maar beschikken ze niet over de "read:orders" of "list:orders" scopes.

Het concept van eigenaarschap speelt een cruciale rol bij het definiëren van toegangscontrole voor specifieke middelen in een REST API. Door te erkennen dat gebruikers altijd toegang hebben tot hun eigen middelen, kunnen we efficiëntere en veiligere toegangscontrole implementeren zonder onnodige machtigingen toe te kennen. In het geval van BookHarber betekent dit dat klanten nog steeds hun bestellingen kunnen bekijken en beheren zonder dat er aanvullende scopes nodig zijn.

Om te demonstreren hoe dit werkt, laten we kijken naar het GET /orders eindpunt:

1. Als een gebruiker de list:orders scope heeft (bijvoorbeeld winkelbeheerders of medewerkers), zullen ze in staat zijn om alle bestellingen in het systeem te bekijken. Dit biedt hen een uitgebreid overzicht van de bestelgegevens die nodig zijn voor hun rol.
2. Als een gebruiker niet de list:orders scope heeft (bijvoorbeeld gewone klanten), zal het systeem alleen de bestellingen retourneren die bij de gebruiker horen. Dit zorgt ervoor dat klanten nog steeds toegang hebben tot hun bestelgegevens zonder dat er onnodige machtigingen worden verleend.

Door deze eigenaarschap-gebaseerde toegangscontrole te implementeren, kan de API het juiste niveau van toegang bieden aan verschillende gebruikersrollen, terwijl de beveiliging en een op maat gemaakte gebruikerservaring behouden blijven. In het geval van BookHarber stelt het eigenaarschapsmodel klanten in staat om toegang te krijgen tot hun bestelinformatie zonder de noodzaak van "read:orders" of "list:orders" scopes, wat het ontwerp van de toegangscontrole vereenvoudigt en de algehele gebruikerservaring verbetert.

Configuratie-instellingen in de Logto Console#

Om de configuratie in de Logto Console te voltooien, volg je deze stappen:

1. Maak een Single Page Application (SPA) voor React: Stel een SPA in de Logto Console in voor je React applicatie.
2. Maak een API-resource aan: Voeg een nieuwe API-resource toe met de identifier https://api.bookharber.com.
3. Definieer scopes voor de resource: Maak de benodigde scopes aan onder de nieuw aangemaakte API-resource.
4. Maak rollen aan en wijs scopes toe: Definieer de gebruikersrollen voor je applicatie en wijs de juiste scopes toe aan elke rol.
5. Wijs rollen toe aan gebruikers: Wijs de relevante rollen toe aan de gebruikers in je applicatie, zorg ervoor dat elke gebruiker (vooral personeelsleden) de juiste machtigingen heeft op basis van hun rol.

Beveilig de API met scopes#

In ons voorbeeldproject, BookHarber, gebruiken we Express voor de back-end service en React voor de front-end webpagina. Deze sectie biedt een kort overzicht van hoe we de RBAC-functies van Logto kunnen integreren in deze populaire technologieën om onze applicatie te beveiligen.

De volledige documentatie: https://docs.logto.io/docs/recipes/rbac/protect-resource

Frontend#

Om Logto te initialiseren in je React applicatie, volg de documentatie hier: https://docs.logto.io/docs/recipes/integrate-logto/react/

Naast de basisinstallatie moet je de "resource" en "scopes" specificeren in de configuratie:

Hier is een voorbeeld van hoe je een API-aanvraag kunt doen met Logto:

Backend#

Om de API te beschermen, volg: https://docs.logto.io/docs/recipes/protect-your-api/

Naast de voorbeeldcode (https://docs.logto.io/docs/recipes/protect-your-api/node), moeten we de scope-validatie toevoegen:

Conclusie#

Logto's RBAC-systeem is een krachtig hulpmiddel voor het beheren van toegangscontrole en beveiliging in moderne applicaties. Door gebruik te maken van de RBAC-functies van Logto kun je ervoor zorgen dat gebruikers geschikte toegang hebben tot middelen op basis van hun rollen, waardoor gevoelige gegevens en functionaliteit worden beschermd tegen ongeautoriseerde toegang.

In dit artikel hebben we een praktijkvoorbeeld van een online boekwinkel, BookHarber, onderzocht en gedemonstreerd hoe we scopes kunnen ontwerpen, ze kunnen toewijzen aan gebruikersrollen en de RBAC-functies van Logto kunnen implementeren in zowel de front-end als de back-end van de applicatie.

Door deze concepten en technieken toe te passen op je projecten, kun je de beveiliging en toegangscontrole van je applicaties verbeteren, en een naadloze en veilige gebruikerservaring bieden. Of je nu werkt aan een e-commerceplatform, een content managementsysteem, of een ander project dat rolgebaseerde toegang vereist, Logto's RBAC-systeem biedt een flexibele en efficiënte oplossing om aan je toegangscontrolenoden te voldoen.