Svenska

ciam
auth
authorization

CIAM 102: Auktorisation & Rollbaserad åtkomstkontroll

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

Gao

Founder

2/5/2023

Sluta slösa veckor på användarautentisering

Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.

Kom igång

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.

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?

Bakgrund#

Varför behöver vi auktorisation?#

Den grundläggande auktorisationsmodellen#

Rollbaserad åtkomstkontroll#

Definiera resurser#

Definiera behörigheter#

Definiera roller#

Tilldela roller till användare#

Koppla samman punkterna#

Andra RBAC-nivåer#

I praktiken#

Avslutande anmärkningar#

Bakgrund#

Varför behöver vi auktorisation?#

Den grundläggande auktorisationsmodellen#

Rollbaserad åtkomstkontroll#

Definiera resurser#

Definiera behörigheter#

Definiera roller#

Tilldela roller till användare#

Koppla samman punkterna#

Andra RBAC-nivåer#

I praktiken#

Avslutande anmärkningar#

Bakgrund

Varför behöver vi auktorisation?

Den grundläggande auktorisationsmodellen

Rollbaserad åtkomstkontroll

Definiera resurser

Definiera behörigheter

Definiera roller

Tilldela roller till användare

Koppla samman punkterna

Andra RBAC-nivåer

I praktiken

Avslutande anmärkningar

Bakgrund

Varför behöver vi auktorisation?

Den grundläggande auktorisationsmodellen

Rollbaserad åtkomstkontroll

Definiera resurser

Definiera behörigheter

Definiera roller

Tilldela roller till användare

Koppla samman punkterna

Andra RBAC-nivåer

I praktiken

Avslutande anmärkningar