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).
GaoFounder
Stop met weken verspillen aan gebruikersauthenticatie
Lanceer veilige apps sneller met Logto. Integreer gebruikersauthenticatie in minuten en focus op je kernproduct.
In het vorige artikel 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).
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.
Hier is een van de meest voorkomende AuthZ-modellen: Als IDENTITEITACTIE 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 Niveau 1: Vlakke RBAC.
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.
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:
Hoewel er geen vereiste is voor de naam van een permissie, hebben we de conventie als volgt:
Terwijl <actie> vereist is om een permissie te beschrijven, kan :<doel> 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.
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.
Hier is een compleet relatie diagram voor het Niveau 1 RBAC-model in Logto:
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.
Zie het document 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!
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 om te leren hoe je RBAC in Logto kunt gebruiken.