CIAM 102: Autorisatie & Rolgebaseerde Toegangscontrole

Achtergrond#

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).

Waarom hebben we autorisatie nodig?#

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 Niveau 1: Vlakke RBAC.

Rolgebaseerde Toegangscontrole#

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.

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 <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.

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:

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:

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 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 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?