Polski

ciam
auth
autoryzacja

CIAM 102: Uprawnienia & Kontrola dostępu oparta na rolach

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

Gao

Founder

2/5/2023

Przestań tracić tygodnie na uwierzytelnianie użytkowników

Uruchamiaj bezpieczne aplikacje szybciej z Logto. Zintegruj uwierzytelnianie użytkowników w kilka minut i skup się na swoim głównym produkcie.

Rozpocznij

Tło

W poprzednim artykule, wprowadziliśmy pojęcie uwierzytelniania (AuthN) i autoryzacji (AuthZ), wraz z niektórymi bolesnymi dla głowy terminami: tożsamość, organizacja, najemca, itp.

Dlaczego potrzebujemy autoryzacji?

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 Poziom 1: Płaski RBAC.

Kontrola dostępu oparta na rolach

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.

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 <action> jest wymagane do opisania uprawnienia, :<target> 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:

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:

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

Tło#

Dlaczego potrzebujemy autoryzacji?#

Podstawowy model autoryzacji#

Kontrola dostępu oparta na rolach#

Zdefiniuj zasoby#

Zdefiniuj uprawnienia#

Zdefiniuj role#

Przypisz role użytkownikom#

Połącz kropki#

Inne poziomy RBAC#

W praktyce#

Notatki końcowe#

Tło#

Dlaczego potrzebujemy autoryzacji?#

Podstawowy model autoryzacji#

Kontrola dostępu oparta na rolach#

Zdefiniuj zasoby#

Zdefiniuj uprawnienia#

Zdefiniuj role#

Przypisz role użytkownikom#

Połącz kropki#

Inne poziomy RBAC#

W praktyce#

Notatki końcowe#

Tło

Dlaczego potrzebujemy autoryzacji?

Podstawowy model autoryzacji

Kontrola dostępu oparta na rolach

Zdefiniuj zasoby

Zdefiniuj uprawnienia

Zdefiniuj role

Przypisz role użytkownikom

Połącz kropki

Inne poziomy RBAC

W praktyce

Notatki końcowe

Tło

Dlaczego potrzebujemy autoryzacji?

Podstawowy model autoryzacji

Kontrola dostępu oparta na rolach

Zdefiniuj zasoby

Zdefiniuj uprawnienia

Zdefiniuj role

Przypisz role użytkownikom

Połącz kropki

Inne poziomy RBAC

W praktyce

Notatki końcowe