CIAM 102: Auktorisation & Rollbaserad åtkomstkontroll

Bakgrund#

I den föregående artikeln introducerade vi konceptet autentisering (AuthN) och auktorisation (AuthZ), tillsammans med några besvärliga termer: Identitet, Organisation, Hyresgäst, etc.

Organisation och Hyresgäst är bra för att gruppera Identiteter, men de leder till en absolut demokrati: alla kan göra vad som helst i detta system. Även om utopi fortfarande är ett mysterium, låt oss titta på styrningen av åtkomst: Auktorisation (AuthZ).

Varför behöver vi auktorisation?#

Notion är ett bra exempel. För varje sida du äger kan du välja att hålla den privat, endast tillgänglig för dig, eller dela den med vänner, eller till och med publikt.

Eller, för en onlinebokhandel, vill du att alla ska kunna se alla böcker, men kunder ska endast se sina egna beställningar, och säljare ska bara hantera böckerna i sina butiker.

AuthZ och AuthN är väsentliga komponenter i en komplex affärsmodell. De går ofta hand i hand; AuthZ verifierar en användares åtkomst, medan AuthN autentiserar identiteter. Båda är nödvändiga för ett säkert system.

Den grundläggande auktorisationsmodellen#

Här är en av de vanligaste AuthZ-modellerna: Om IDENTITET utför AKTION på RESURS, då ACCEPTERA eller AVSLA.

I Notion-exemplet är modellen PERSON utför VISA på SIDA.

Om sidan är privat:

• Du får ACCEPTERA när du utför VISA på din SIDA.
• Alla andra bör få AVSLA när de utför VISA på din SIDA.

Baserat på konsensus utvecklade industrin olika auktorisationsteknologier, såsom rollbaserad åtkomstkontroll (RBAC), attributbaserad åtkomstkontroll (ABAC). Idag fokuserar vi på NIST RBAC-modellen Nivå 1: Flat RBAC.

Rollbaserad åtkomstkontroll#

Låt oss utöka bokhandelsexemplet. Säg att vi har många kunder, men endast en säljare:

• Kunder kan se och beställa böcker, samt se sina egna beställningar.
• Säljaren kan se, skapa och ta bort böcker, samt hantera kundbeställningar.

Definiera resurser#

I Logto representerar en resurs (dvs. API Resurs) vanligtvis en uppsättning av enheter eller objekt, eftersom det krävs att använda en giltig URL som indikator. Därför definierar vi två resurser:

• Böcker: https://api.bookstore.io/books
• Beställningar: https://api.bookstore.io/orders

En av fördelarna med att upprätthålla URL-formatet är att det kan mappa till en riktig adress för din API-tjänst, vilket förbättrar läsbarheten och igenkännbarheten när du integrerar med andra komponenter i systemet.

Definiera behörigheter#

Eftersom vi introducerade begreppet resurs, upprätthåller vi också i Logto att behörigheter måste tillhöra en resurs, och resurser kan i sin tur ha behörigheter.

Låt oss lägga till några behörigheter till resurserna:

• Böcker: läsa, skapa, ta bort
• Beställningar: läsa, läsa:själv, skapa:själv, ta bort

Även om det inte finns något krav på namnet på en behörighet, har vi konventionen nedan:

Medan <aktion> krävs för att beskriva en behörighet, kan :<mål> ignoreras för att beskriva ett allmänt mål, dvs. till alla enheter eller objekt i resursen. Till exempel:

• Behörigheten läsa i resursen Böcker betyder aktionen att läsa godtyckliga böcker.
• Behörigheten skapa:själv i resursen Beställningar betyder aktionen att skapa beställningar som tillhör den nuvarande användaren.

Definiera roller#

Kort sagt, en roll är en grupp av behörigheter. Låt oss skapa två roller kund och säljare och tilldela behörigheter till dem enligt nedan:

Du kan märka att behörighet-roll tilldelningen är många-till-många relationer.

Tilldela roller till användare#

Precis som roll-behörighet tilldelning är användare-roll tilldelning också en många-till-många relation. Därför kan du tilldela flera roller till en enda användare, och en enda roll kan tilldelas till flera användare.

Koppla samman punkterna#

Här är ett komplett relationsdiagram för Nivå 1 RBAC-modellen i Logto:

I RBAC-modellen är behörigheterna alltid "positiva", vilket betyder att auktorisationsbedömningen är enkel: om en användare har behörighet, acceptera; annars, avvisa.

Låt oss säga att Alice har rollen säljare, Bob och Carol har rollen kund. Vi beskriver handlingar i naturligt språk först, och översätter dem till det standardiserade auktorisationsformatet: IDENTITET utför AKTION på RESURS, slutligen ger vi slutsatsen.

• Alice vill lägga till en ny bok till försäljning:
  • Användare Alice utför skapa på resursen Böcker (https://api.bookstore.io/books).
  • Eftersom Alice har tilldelats behörigheten skapa av Böcker enligt sin roll säljare, är resultatet ✅ ACCEPTERA.
• Alice vill se alla beställningar för att se om försäljningen möter deras förväntningar:
  • Användare Alice utför läsa på resursen Beställningar (https://api.bookstore.io/orders).
  • Eftersom Alice har tilldelats behörigheten läsa av Beställningar enligt sin roll säljare, är resultatet ✅ ACCEPTERA.
• Bob vill bläddra i boklistan för att se om det finns några böcker han vill köpa.
  • Användare Bob utför läsa på resursen Böcker (https://api.bookstore.io/books).
  • Eftersom Bob har tilldelats behörigheten läsa av Böcker enligt sin roll kund, är resultatet ✅ ACCEPTERA.
• Bob vill se Carols beställning.
  • Eftersom det är någon annans beställning fungerar inte behörigheten läsa:själv av Beställningar här.
  • Användare Bob utför läsa på resursen Beställningar (https://api.bookstore.io/order).
  • Eftersom Bob inte har behörigheten läsa av Beställningar, är resultatet ❌ AVSLA.

Andra RBAC-nivåer#

Det finns fyra nivåer i NIST RBAC-modellen:

• Flat RBAC
• Hierarkisk RBAC
• Begränsad RBAC
• Symmetrisk RBAC

Se artikeln för detaljer om du är intresserad.

Logto har nu implementeringen av Nivå 1 och kommer att gå vidare till högre nivåer baserat på feedback från samhället. Tveka inte att meddela oss om en högre nivå passar dina behov!

I praktiken#

Förutom teorin, har vi fortfarande många tekniska arbeten att slutföra för att få modellen att fungera som förväntat:

• Klient- och autentiseringsserverutveckling
• Databaseriktning för RBAC
• Validering över olika tjänster
• Säkerhet och efterlevnad av öppna standarder
• Roll, behörighet, resursförvaltning och tilldelning

Ingen panik. Vi har tagit hänsyn till detta och lagt till stöd direkt ur lådan för att täcka allt ovan. Kolla in 🔐 RBAC-receptet för att lära dig hur man använder RBAC i Logto.

Avslutande anmärkningar#

RBAC är en kraftfull åtkomsthanteringsmodell för de flesta fall, men det finns ingen universallösning. Vi har fortfarande några frågor:

• Behöver jag höga nivåer av RBAC?
• Hur står sig RBAC i jämförelse med andra auktorisationsmodeller?
• Hur definierar man auktorisationsmodell mellan olika Organisationer?