## Bakgrund I den [föregående artikeln](/ciam-101-intro-authn-sso/) 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? Auktorisation (AuthZ) svarar på frågan "Vad kan du göra?" 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](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) Nivå 1: Flat RBAC. ## Rollbaserad åtkomstkontroll NIST RBAC-modellen lämnade många saker öppna för att ge flexibilitet och anpassningsbarhet för olika scenarier. Logto antar nu Nivå 1-definitionen med ett ytterligare koncept "Resurs" (dvs. API Resurs). 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. 🤔 Resurser bör delas in enligt företagsbehoven. Det finns ingen universallösning; beslutet bör fattas från fall till fall. Exemplet i denna artikel som delar Böcker och Beställningar kan vara lämpligt för mikrotjänster, men inte för en monolitisk arkitektur. ### 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 `` krävs för att beskriva en behörighet, kan `:` 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: ```mermaid erDiagram Role-Customer { permission Books "läsa" permission Orders "läsa:själv" permission Orders "skapa:själv" } Role-Seller { permission Books "läsa" permission Books "skapa" permission Books "ta bort" permission Orders "läsa" permission Orders "ta bort" } ``` 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: ```mermaid erDiagram User }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` 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](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) 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](https://docs.logto.io/docs/recipes/rbac/) 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? 🔥 Håll dig uppdaterad. Vi ses i CIAM 103!