## Achtergrond In het [vorige artikel](/ciam-101-intro-authn-sso/) introduceerden we het concept van authenticatie (AuthN) en autorisatie (AuthZ), samen met enkele hoofdbrekende termen: Identiteit, Organisatie, Tenant, enz. Organisatie en Tenant zijn geweldig voor het groeperen van Identiteiten, maar ze leiden tot een absolute democratie: iedereen kan alles doen in dit systeem. Terwijl utopie nog steeds een mysterie is, laten we eens kijken naar het beheer van toegang: Autorisatie (AuthZ). ### Waarom hebben we autorisatie nodig? Autorisatie (AuthZ) beantwoordt de vraag "Wat kun je doen?" Notion is een geweldig voorbeeld. Voor elke pagina die je bezit, kun je kiezen om deze privé te houden, alleen toegankelijk voor jou, of om deze te delen met vrienden of zelfs het publiek. Of, voor een online boekwinkel wil je dat iedereen alle boeken kan bekijken, maar dat klanten alleen hun eigen bestellingen kunnen bekijken, en dat verkopers alleen de boeken in hun winkels kunnen beheren. AuthZ en AuthN zijn essentiële onderdelen van een complex bedrijfsmodel. Ze gaan vaak hand in hand; AuthZ verifieert de toegang van een gebruiker, terwijl AuthN identiteiten authenticiteit. Beide zijn noodzakelijk voor een veilig systeem. ## Het basis autorisatiemodel Hier is een van de meest voorkomende AuthZ-modellen: Als **IDENTITEIT** **ACTIE** uitvoert op **BRON**, dan **ACCEPTEER** of **WEIGER**. In het Notion-voorbeeld is het model **PERSOON** voert **BEKIJKEN** uit op **PAGINA.** Als de pagina privé is: - Je ontvangt **ACCEPTEER** wanneer je **BEKIJKEN** uitvoert op je **PAGINA**. - Iedereen anders zou **WEIGER** moeten ontvangen wanneer ze **BEKIJKEN** uitvoeren op jouw **PAGINA**. Op basis van consensus heeft de industrie verschillende autorisatietechnologieën ontwikkeld, zoals Rolgebaseerde Toegangscontrole (RBAC), Attribuut-gebaseerde Toegangscontrole (ABAC). Vandaag richten we ons op het [NIST RBAC-model](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) Niveau 1: Vlakke RBAC. ## Rolgebaseerde Toegangscontrole Het NIST RBAC-model liet veel dingen open om flexibiliteit en aanpasbaarheid voor verschillende scenario's te bieden. Logto hanteert nu de Niveau 1-definitie met een extra concept "Bron" (i.e. API Bron). Laten we het boekwinkelvoorbeeld uitbreiden. Stel dat we veel klanten hebben, maar slechts één verkoper: - Klanten kunnen boeken bekijken en bestellen, evenals hun eigen bestellingen bekijken. - De verkoper kan boeken bekijken, maken en verwijderen, en klantenbestellingen beheren. ### Bepaal bronnen In Logto vertegenwoordigt een bron (i.e. API Bron) meestal een set entiteiten of items, aangezien het nodig is om een geldige URL als indicator te gebruiken. Daarom definiëren we twee bronnen: - Boeken: `https://api.bookstore.io/books` - Bestellingen: `https://api.bookstore.io/orders` Een van de voordelen van het afdwingen van het URL-formaat is dat het kan verwijzen naar een echt adres van je API-service, wat de leesbaarheid en herkenbaarheid verbetert bij integratie met andere componenten in het systeem. 🤔 Bronnen moeten worden verdeeld volgens de behoeften van het bedrijf. Er is geen pasklare aanpak; de beslissing moet van geval tot geval worden genomen. Het voorbeeld in dit artikel dat Boeken en Bestellingen verdeelt, kan geschikt zijn voor microservices, maar niet voor een monolithische architectuur. ### Bepaal permissies Aangezien we het concept van bron hebben geïntroduceerd, dwingt Logto ook af dat permissies bij een bron moeten horen, omgekeerd kunnen bronnen permissies hebben. Laten we enkele permissies toevoegen aan de bronnen: - Boeken: `lezen`, `maken`, `verwijderen` - Bestellingen: `lezen`, `lezen:zelf`, `maken:zelf`, `verwijderen` Hoewel er geen vereiste is voor de naam van een permissie, hebben we de conventie als volgt: ``` [:] ``` Terwijl `` vereist is om een permissie te beschrijven, kan `:` worden genegeerd om een algemeen doel te beschrijven, i.e. voor alle entiteiten of items in de bron. Bijvoorbeeld: - Permissie `lezen` in bron Boeken betekent de actie om willekeurige boeken te lezen. - Permissie `maken:zelf` in bron Bestellingen betekent de actie om bestellingen te maken die bij de huidige gebruiker horen. ### Bepaal rollen Kortom, een rol is een groep van permissies. Laten we twee rollen maken `klant` en `verkoper` en de volgende permissies aan hen toewijzen: ```mermaid erDiagram Role-Customer { permission Books "lezen" permission Orders "lezen:zelf" permission Orders "maken:zelf" } Role-Seller { permission Books "lezen" permission Books "maken" permission Books "verwijderen" permission Orders "lezen" permission Orders "verwijderen" } ``` Je zult merken dat de permissie-rol toewijzing een veel-op-veel relatie is. ### Wijs rollen toe aan gebruikers Net als bij rol-permissie toewijzing, is gebruikers-rol toewijzing ook een veel-op-veel relatie. Dus, je kunt meerdere rollen aan één gebruiker toewijzen, en één rol kan aan meerdere gebruikers worden toegewezen. ### Verbind de stippen Hier is een compleet relatie diagram voor het Niveau 1 RBAC-model in Logto: ```mermaid erDiagram User }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` In het RBAC-model zijn permissies altijd "positief", wat betekent dat de autorisatiebeoordeling eenvoudig is: als een gebruiker de permissie heeft, accepteer; anders, weiger. Stel dat Alice de rol `verkoper` heeft, Bob en Carol hebben de rol `klant`. We beschrijven acties eerst in natuurlijke taal en vertalen ze naar het standaard autorisatieformaat: **IDENTITEIT** voert **ACTIE** uit op **BRON**, uiteindelijk met de conclusie. - Alice wil een nieuw boek te koop aanbieden: - Gebruiker Alice voert `maken` uit op bron Boeken (`https://api.bookstore.io/books`). - Omdat Alice de permissie `maken` van Boeken heeft toegewezen gekregen volgens hun rol `verkoper`, is het resultaat ✅ **ACCEPTEER**. - Alice wil alle bestellingen bekijken om te zien of de verkoop aan hun verwachtingen voldoet: - Gebruiker Alice voert `lezen` uit op bron Bestellingen (`https://api.bookstore.io/orders`). - Omdat Alice de permissie `lezen` van Bestellingen heeft toegewezen gekregen volgens hun rol `verkoper`, is het resultaat ✅ **ACCEPTEER**. - Bob wil de boekenlijst doorbladeren om te zien of er boeken zijn die hij wil kopen. - Gebruiker Bob voert `lezen` uit op bron Boeken (`https://api.bookstore.io/books`). - Omdat Bob de permissie `lezen` van Boeken heeft toegewezen gekregen volgens zijn rol `klant`, is het resultaat ✅ **ACCEPTEER**. - Bob wil de bestelling van Carol bekijken. - Aangezien het een bestelling van iemand anders is, werkt de permissie `lezen:zelf` van `Bestellingen` hier niet. - Gebruiker Bob voert `lezen` uit op bron Bestellingen (`https://api.bookstore.io/orders`). - Omdat Bob geen permissie `lezen` van Bestellingen heeft, is het resultaat ❌ **WEIGER**. ### Andere RBAC-niveaus Er zijn vier niveaus in het NIST RBAC-model: - Vlakke RBAC - Hiërarchische RBAC - Beperkte RBAC - Symmetrische RBAC Zie het [document](https://csrc.nist.gov/CSRC/media/Publications/conference-paper/2000/07/26/the-nist-model-for-role-based-access-control-towards-a-unified-/documents/sandhu-ferraiolo-kuhn-00.pdf) voor meer details als je geïnteresseerd bent. Logto heeft momenteel de implementatie van Niveau 1 en zal voortgang boeken naar hogere niveaus op basis van feedback uit de gemeenschap. Aarzel niet om ons te laten weten of een hoger niveau aan je behoeften voldoet! ## In de praktijk Naast de theorie hebben we nog zware technische werkzaamheden te voltooien om het model naar verwachting te laten werken: - Ontwikkeling van client en auth-server - Databaseontwerp voor RBAC - Validatie over verschillende diensten - Naleving van beveiliging en open-standaard - Beheer en toewijzing van rol, permissie, bron Geen paniek. We hebben hiermee rekening gehouden en out-of-the-box ondersteuning toegevoegd om al het bovenstaande te dekken. Bekijk het [🔐 RBAC-recept](https://docs.logto.io/docs/recipes/rbac/) om te leren hoe je RBAC in Logto kunt gebruiken. ## Slotopmerkingen RBAC is een krachtig toegangsbeheer model voor de meeste gevallen, maar het is geen wondermiddel. We hebben nog steeds enkele vragen: - Heb ik hoge niveaus van RBAC nodig? - Hoe verhoudt RBAC zich tot andere autorisatiemodellen? - Hoe definieer ik een autorisatiemodel tussen verschillende Organisaties? 🔥 Blijf op de hoogte. We zien je in CIAM 103!