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

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.

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?#

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?