## Tło W [poprzednim artykule](/ciam-101-intro-authn-sso/), wprowadziliśmy pojęcie uwierzytelniania (AuthN) i autoryzacji (AuthZ), wraz z niektórymi bolesnymi dla głowy terminami: tożsamość, organizacja, najemca, itp. Organizacja i najemca są świetne do grupowania tożsamości, ale prowadzą do absolutnej demokracji: każdy może robić cokolwiek w tym systemie. Podczas gdy utopia jest nadal tajemnicą, spójrzmy na zarządzanie dostępem: Autoryzacja (AuthZ). ### Dlaczego potrzebujemy autoryzacji? Autoryzacja (AuthZ) odpowiada na pytanie "Co możesz zrobić?" Notion jest świetnym przykładem. Na każdej stronie, którą posiadasz, możesz wybrać, czy ma być prywatna, dostępna tylko dla Ciebie, czy też udostępnić ją znajomym, a nawet publiczności. Lub, w przypadku księgarni internetowej, chcesz, aby każdy mógł przeglądać wszystkie książki, ale klienci mogli oglądać tylko swoje zamówienia, a sprzedawcy zarządzać tylko książkami w swoich sklepach. AuthZ i AuthN są niezbędnymi składnikami skomplikowanego modelu biznesowego. Często idą one w parze; AuthZ weryfikuje dostęp użytkownika, podczas gdy AuthN uwierzytelnia tożsamości. Obie są niezbędne dla bezpiecznego systemu. ## Podstawowy model autoryzacji Oto jeden z najczęstszych modeli AuthZ: Jeśli **TOŻSAMOŚĆ** wykonuje **AKCJĘ** na **ZASOBIE**, to **AKCEPTUJ** lub **ODMÓW**. W przypadku Notion model ten przyjmuje postać: **CZŁOWIEK** wykonuje **PRZEGLĄD** na **STRONIE**. Jeśli strona jest prywatna: - Otrzymasz **AKCEPTUJ** podczas wykonywania **PRZEGLĄD** na twojej **STRONIE**. - Każdy inny powinien otrzymać **ODMÓW** podczas wykonywania **PRZEGLĄD** na twojej **STRONIE**. Na podstawie konsensusu branża opracowała różne technologie autoryzacji, takie jak kontrola dostępu oparta na rolach (RBAC), kontrola dostępu oparta na atrybutach (ABAC). Dziś skupimy się na modelu [NIST RBAC](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) Poziom 1: Płaski RBAC. ## Kontrola dostępu oparta na rolach Model NIST RBAC pozostawił wiele rzeczy otwartych, aby zapewnić elastyczność i zdolność do adaptacji do różnych scenariuszy. Logto teraz stosuje definicję poziomu 1 z dodatkowym pojęciem "Zasób" (tj. Zasób API) Rozszerzmy przykład księgarni. Załóżmy, że mamy wielu klientów, ale tylko jednego sprzedawcę: - Klienci mogą przeglądać i zamawiać książki, a także przeglądać swoje zamówienia. - Sprzedawca może przeglądać, tworzyć i usuwać książki, a także zarządzać zamówieniami klientów. ### Zdefiniuj zasoby W Logto, zasób (tj. Zasób API) zwykle reprezentuje zestaw jednostek lub elementów, ponieważ jest wymagane użycie prawidłowego URL jako wskaźnika. Stąd zdefiniowaliśmy dwa zasoby: - Książki: `https://api.bookstore.io/books` - Zamówienia: `https://api.bookstore.io/orders` Jedną z zalet wymuszania formatu URL jest to, że można go zmapować na rzeczywisty adres Twojej usługi API, co poprawia czytelność i rozpoznawalność podczas integrowania z innymi komponentami w systemie. 🤔 Zasoby powinny być dzielone zgodnie z potrzebami biznesu. Nie ma podejścia pasującego do wszystkich; decyzja powinna być podejmowana w każdym przypadku indywidualnie. Przykład z tego artykułu, który dzieli książki i zamówienia, może pasować do mikrousług, ale nie do architektury monolitycznej. ### Zdefiniuj uprawnienia Ponieważ wprowadziliśmy pojęcie zasobu, w Logto, egzekwujemy również, że uprawnienia muszą należeć do zasobu, w przeciwnym razie, zasoby mogą mieć uprawnienia. Dodajmy jakieś uprawnienia do zasobów: - Książki: `read`, `create`, `delete` - Zamówienia: `read`, `read:self`, `create:self`, `delete` Chociaż nie ma wymogu na nazwę uprawnienia, mamy konwencję poniżej: ``` [:] ``` Podczas gdy `` jest wymagane do opisania uprawnienia, `:` można zignorować, aby opisać ogólny cel, tj. do wszystkich jednostek lub elementów w zasobie. Na przykład: - Uprawnienie `read` w zasobie Książki oznacza działanie czytania dowolnych książek. - Uprawnienie `create:self` w zasobie Zamówienia oznacza działanie tworzenia zamówień należących do aktualnego użytkownika. ### Zdefiniuj role W skrócie, rola to grupa uprawnień. Stwórzmy dwie role `customer` i `seller` i przypiszmy im uprawnienia w następujący sposób: ```mermaid erDiagram Role-Customer { permission Books "read" permission Orders "read:self" permission Orders "create:self" } Role-Seller { permission Books "read" permission Books "create" permission Books "delete" permission Orders "read" permission Orders "delete" } ``` Możliwe, że zauważyłeś, że przypisanie uprawnień do roli to relacje wiele-do-wiele. ### Przypisz role użytkownikom Tak samo jak przypisanie roli-uprawnienie, przypisanie użytkownik-rola to też relacja wiele-do-wiele. Dlatego możesz przypisać wiele ról do jednego użytkownika, a jedną rolę można przypisać do wielu użytkowników. ### Połącz kropki Oto kompleksowy diagram relacji dla modelu RBAC na poziomie 1 w Logto: ```mermaid erDiagram User }|--|{ Role : maps Role }|--|{ Permission : maps "API Resource" ||--|{ Permission : contains ``` W modelu RBAC, uprawnienia są zawsze "pozytywne", co oznacza, że ocena autoryzacji jest prosta: jeśli użytkownik ma uprawnienie, to akceptuj; w przeciwnym razie odrzuć. Powiedzmy, że Alice ma rolę `seller`, Bob i Carol mają rolę `customer`. Opiszemy akcje najpierw w języku naturalnym, a następnie przekonwertujemy je na standardowy format autoryzacji: **TOŻSAMOŚĆ** wykonuje **AKCJĘ** na **ZASOBIE**, na koniec dając wniosek. - Alice chce dodać nową książkę do sprzedaży: - Użytkownik Alice wykonuje `create` na zasobie Książki (`https://api.bookstore.io/books`). - Ponieważ Alice została przypisana uprawnienie `create` Książek zgodnie z ich rolą `seller`, wynik to ✅ **AKCEPTUJ**. - Alice chce zobaczyć wszystkie zamówienia, aby sprawdzić, czy sprzedaż spełnia jej oczekiwania: - Użytkownik Alice wykonuje `read` na zasobie Zamówienia (`https://api.bookstore.io/orders`). - Ponieważ Alice została przypisana uprawnienie `read` Zamówień zgodnie z ich rolą `seller`, wynik to ✅ **AKCEPTUJ**. - Bob chce przeglądać listę książek, aby zobaczyć, czy są tam jakieś książki, które chciałby kupić. - Użytkownik Bob wykonuje `read` na zasobie Książki (`https://api.bookstore.io/books`). - Ponieważ Bob został przypisany uprawnienie `read` Książek zgodnie z ich rolą `customer`, wynik to ✅ **AKCEPTUJ**. - Bob chce zobaczyć zamówienie Carol. - Ponieważ jest to zamówienie kogoś innego, uprawnienie `read:self` do `Orders` tutaj nie działa. - Użytkownik Bob wykonuje `read` na zasobie Zamówienia (`https://api.bookstore.io/order`). - Ponieważ Bob nie ma uprawnienia `read` do Zamówień, wynik to ❌ **ODMÓW**. ### Inne poziomy RBAC Model NIST RBAC ma cztery poziomy: - Płaski RBAC - Hierarchiczny RBAC - Ograniczony RBAC - Symetryczny RBAC Zobacz [artykuł](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) po szczegóły, jeśli jesteś zainteresowany. Logto ma teraz implementację Poziomu 1 i będzie rozwijać wyższe poziomy na podstawie opinii społeczności. Nie wahaj się dać nam znać, jeśli wyższy poziom pasuje do Twoich potrzeb! ## W praktyce Oprócz teorii, mamy jeszcze dużo technicznej pracy do wykonania, aby model działał zgodnie z oczekiwaniami: - Rozwój klienta i serwera autoryzacji - Projektowanie bazy danych dla RBAC - Walidacja między różnymi usługami - Zgodność z zabezpieczeniami i otwartymi standardami - Zarządzanie rolami, uprawnieniami, zasobami i przyporządkowaniem Nie panikuj. Wzięliśmy to pod uwagę i dodaliśmy wsparcie 'out-of-the-box', żeby pokryć wszystko powyżej. Sprawdź [🔐 przepis na RBAC](https://docs.logto.io/docs/recipes/rbac/), aby dowiedzieć się, jak używać RBAC w Logto. ## Notatki końcowe RBAC to potężny model zarządzania dostępem w większości przypadków, ale nie ma srebrnego pocisku. Mamy jeszcze kilka pytań: - Czy potrzebuję wysokich poziomów RBAC? - Jak RBAC porównuje się do innych modeli autoryzacji? - Jak zdefiniować model autoryzacji pomiędzy różnymi organizacjami? 🔥 Bądź na bieżąco. Do zobaczenia w CIAM 103!