Behärska RBAC i Logto: Ett omfattande verklighetsexempel

Introduktion#

Åtkomstkontroll och säkerhet är viktiga aspekter av moderna applikationer, som säkerställer att användare har lämplig åtkomst till resurser. Logtos Rollbaserade åtkomstkontroll (RBAC) erbjuder utvecklare ett effektivt sätt att hantera åtkomstkontroll och säkerhet i sina applikationer. I denna artikel kommer vi att utforska de kraftfulla funktionerna i Logtos RBAC-implementering med hjälp av ett verkligt exempel, vilket hjälper dig att förstå och tillämpa dessa koncept i dina projekt.

Genom att undersöka både frontend- och backend-kodexempel, kommer du att få en omfattande syn på att integrera Logtos RBAC i din applikationsstack. I slutet av denna artikel kommer du att vara välutrustad för att utnyttja Logtos RBAC-funktioner för att förbättra ditt projekts säkerhet och åtkomstkontroll.

Introducera BookHarber: Ett användarfall för en onlinebokhandel#

För att effektivt demonstrera Logtos RBAC-funktioner, kommer vi att använda ett verkligt exempel: BookHarber, en onlinebokhandel. BookHarber erbjuder ett brett utbud av funktioner för kunder och personal, vilket säkerställer en smidig och säker shoppingupplevelse.

Viktiga funktioner i BookHarber inkluderar:

1. Bläddra och köpa böcker: Användare kan enkelt söka efter och köpa böcker från en mångsidig samling av olika genrer och författare.
2. Orderhantering och logistisk spårning: Registrerade kunder kan hantera sina beställningar, spåra frakt och få uppdateringar om sina köp.
3. Speciella erbjudanden och högtidsaktiviteter: BookHarber ger exklusiva rabatter och kampanjer under speciella evenemang och högtider för att engagera och belöna sin kundbas.
4. Kundsupport: Kunder kan öppna supportärenden för att ta itu med eventuella bekymmer eller problem de kan stöta på, och få snabbt hjälp av BookHarber-personalen.
5. Kundhantering: Personalmedlemmar med olika roller har möjlighet att hantera olika aspekter av plattformen, såsom kundkonton, orderbehandling och problemlösning.

Roller#

I BookHarbers ekosystem kan vi identifiera flera viktiga användarroller, såsom:

1. Gäst: Oregistrerade användare som kan bläddra på webbplatsen, söka efter böcker och se specialerbjudanden.
2. Kund: Registrerade användare som kan köpa böcker, hantera sina beställningar, spåra logistik och öppna supportärenden.
3. Butiksadministratör: Personal ansvarig för att övervaka den övergripande förvaltningen och driften av plattformen. Med full åtkomst.
4. Bokchef: Personal ansvarig för bok- och kategorihantering.
5. Kundtjänstagent: Personal som har i uppgift att svara på supportärenden.
6. Tredjeparts logistikleverantör: Externa partners som ansvarar för att hantera och spåra frakt och leverans av beställningar.
7. Marknadsföringspersonal: Personal som ansvarar för att marknadsföra BookHarber, ansvarig för att hantera specialerbjudanden och evenemang.

Utforma behörighetsområden för BookHarbers REST API:er#

För att effektivt implementera Logtos RBAC-system för BookHarber, måste vi utforma behörighetsområden som motsvarar de olika REST API:erna. Behörighetsområden är tillstånd som definierar åtkomstnivån för en viss roll för varje API slutpunkt. Genom att tilldela lämpliga områden till varje användarroll kan vi säkerställa att användare endast har åtkomst till de åtgärder och resurser som är relevanta för deras roll.

Låt oss designa behörighetsområden för följande REST API:er:

1. Kategorier API:
   • create:categories: POST /categories
   • write:categories: PUT /categories/:id
   • delete:categories: DELETE /categories/:id
   • list:categories: GET /categories
2. Böcker 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. Kunder API:
   • list:customers: GET /customers
   • write:customers: PUT /customers/:id
   • delete:customers: DELETE /customers/:id
   • read:customers: GET /customers/:id
4. Beställningar API:
   • create:orders: POST /orders
   • list:orders: GET /orders
   • read:orders: GET /orders/:id
   • write:orders: PUT /orders/:id
5. Evenemang API:
   • create:events: POST /events
   • write:events: PUT /events/:id
   • list:events: GET /events
   • delete:events: DELETE /events/:id
6. Order Spårning API:
   • read:orderTracks: GET /orders/:id/tracks
   • create:orderTracks: POST /orders/:id/tracks
   • write:orderTracks: PUT /orders/:id/tracks/:trackId
7. Biljetter API:
   • create:tickets: POST /tickets
   • list:tickets: GET /tickets
   • read:tickets: GET /tickets/:id
   • write:tickets: PUT /tickets/:id

Tilldelning av behörighetsområden till roller#

Nu när vi har definierat de lämpliga behörighetsområdena för varje REST API kan vi tilldela dessa områden till respektive användarroll i BookHarbers ekosystem:

Förstå skillnaderna mellan "list" och "read" områden#

För att ytterligare illustrera skillnaderna mellan "list" och "read" områden i samband med REST API-design och RBAC, låt oss överväga ett verkligt exempel med en onlinebokhandel, BookHarber.

Anta att BookHarber har två typer av användare: kunder och kundtjänstmedarbetare. Kunder kan skapa beställningar, medan kundtjänstmedarbetare är ansvariga för att hjälpa kunderna med sina beställningar. Låt oss ta en titt på hur "list" och "read" behörighetsområdena appliceras på orders API-resursen i detta scenario.

1. Listområden: Ett "list" området tillåter användaren att komma åt en samling av enheter i systemet. Till exempel, list:orders området tillåter en användare att hämta en lista över alla tillgängliga beställningar. I BookHarbers sammanhang kan detta området vara användbart för butiksadministratörer eller annan personal som behöver ha en översikt över alla beställningar i systemet. Däremot bör kundtjänstmedarbetare inte kunna få tillgång till hela listan av beställningar, eftersom deras roll är att hjälpa enskilda kunder med deras specifika beställningar.
2. Readområden: Ett "read" området ger användaren tillstånd att komma åt en enstaka enhet med ett givet ID. Till exempel, read:orders området tillåter användaren att visa detaljerad information om en specifik beställning med dess ID. I BookHarbers fall är detta området idealiskt för kundtjänstmedarbetare som behöver få åtkomst till information om en viss kunds beställning. När en kund öppnar ett supportärende kan kundtjänstmedarbetaren använda order-ID:t som anges i ärendet för att komma åt och visa detaljerna för den specifika beställningen.

Förstå ägande: Varför kunder inte behöver "read" eller "list" områden för sina egna beställningar#

I många applikationer är det vanligt att användare har tillgång till sina egna resurser utan att uttryckligen ge dem motsvarande "read" eller "list" områden. Detta beror på att användare betraktas som ägare till dessa resurser och bör naturligt ha tillgång till dem. I vårt BookHarber-exempel kan kunder skapa beställningar men har inte "read:orders" eller "list:orders" områden.

Ägandekonceptet spelar en avgörande roll i att definiera åtkomstkontroll för specifika resurser i en REST API. Genom att erkänna att användare alltid kan få tillgång till sina egna resurser kan vi genomföra mer effektiv och säker åtkomstkontroll utan att ge onödiga tillstånd. I fallet med BookHarber innebär detta att kunder fortfarande kan visa och hantera sina beställningar utan att behöva några ytterligare områden.

För att demonstrera hur detta fungerar, låt oss överväga GET /orders slutpunkten:

1. Om en användare har list:orders området (t.ex. butiksadministratörer eller personalmedlemmar), kommer de att kunna visa alla beställningar i systemet. Detta ger dem en omfattande översikt över orderdata som är nödvändig för deras roll.
2. Om en användare inte har list:orders området (t.ex. vanliga kunder), kommer systemet endast att returnera de beställningar som tillhör användaren. Detta säkerställer att kunder fortfarande kan få åtkomst till sin orderinformation utan att ges onödiga tillstånd.

Genom att implementera denna ägarbaserade åtkomstkontroll kan API:et ge lämplig åtkomstnivå till olika användarroller samtidigt som säkerheten behålls och en anpassad användarupplevelse säkerställs. I BookHarbers scenario tillåter ägarmodellen kunder att få åtkomst till sin orderinformation utan behovet av "read:orders" eller "list:orders" områden, vilket förenklar åtkomstkontrolldesignen och förbättrar den övergripande användarupplevelsen.

Konfigurera inställningar i Logto Console#

För att slutföra konfigurationen i Logtos Console, följ dessa steg:

1. Skapa en Enkel Sidsapplikation (SPA) för React: Ställ in en SPA i Logto Console för din React-applikation.
2. Skapa en API-resurs: Lägg till en ny API-resurs med identifieraren https://api.bookharber.com.
3. Definiera områden för resursen: Skapa de nödvändiga områdena under den nyss skapade API-resursen.
4. Skapa roller och tilldela områden: Definiera användarrollerna för din applikation och tilldela de lämpliga områdena till varje roll.
5. Tilldela roller till användare: Tilldela de relevanta rollerna till användarna i din applikation för att säkerställa att varje användare (speciellt personalmedlemmar) har rätt behörigheter baserat på deras roll.

Skydda API med områden#

I vårt exempelprojekt, BookHarber, använder vi Express för backend-tjänsten och React för frontend-webbsidan. Det här avsnittet kommer att ge en kort översikt över hur vi kan integrera Logtos RBAC-funktioner i dessa populära teknologier för att säkra vår applikation.

Hela dokumentationen: https://docs.logto.io/docs/recipes/rbac/protect-resource

Frontend#

För att initiera Logto i din React-applikation, följ dokumentationen som finns här: https://docs.logto.io/docs/recipes/integrate-logto/react/

Förutom den grundläggande konfigurationen måste du specificera "resource" och "scopes" i konfigurationen:

Här är ett exempel på hur man gör ett API-anrop med Logto:

Backend#

För att skydda API, följ: https://docs.logto.io/docs/recipes/protect-your-api/

Utöver exempelkoden (https://docs.logto.io/docs/recipes/protect-your-api/node), måste vi lägga till validering av områden:

Slutsats#

Logtos RBAC-system är ett kraftfullt verktyg för att hantera åtkomstkontroll och säkerhet i moderna applikationer. Genom att utnyttja Logtos RBAC-funktioner kan du säkerställa att användare har lämplig åtkomst till resurser baserat på sina roller, och skydda känslig data och funktionalitet från obehörig åtkomst.

I denna artikel utforskade vi ett verkligt exempel på en onlinebokhandel, BookHarber, och visade hur man designar områden, tilldelar dem till användarroller och implementerar Logtos RBAC-funktioner i både frontend och backend av applikationen.

Genom att tillämpa dessa koncept och tekniker på dina projekt kan du förbättra säkerheten och åtkomstkontrollen i dina applikationer, och ge en smidig och säker användarupplevelse. Oavsett om du arbetar på en e-handelsplattform, ett innehållshanteringssystem eller något annat projekt som kräver rollbaserad åtkomstkontroll, erbjuder Logtos RBAC-system en flexibel och effektiv lösning för att möta dina åtkomstkontrollbehov.