Kontrola dostępu oparta na rolach dla deweloperów aplikacji

  • Artykuł

Kontrola dostępu oparta na rolach (RBAC) umożliwia niektórym użytkownikom lub grupom posiadanie określonych uprawnień dostępu do zasobów i zarządzanie nimi. Kontrola dostępu oparta na rolach aplikacji różni się od kontroli dostępu opartej na rolach na platformie Azure i kontroli dostępu opartej na rolach firmy Microsoft. Role niestandardowe platformy Azure i wbudowane role są częścią kontroli dostępu opartej na rolach platformy Azure, która służy do zarządzania zasobami platformy Azure. Kontrola dostępu oparta na rolach firmy Microsoft jest używana do zarządzania zasobami firmy Microsoft Entra. W tym artykule wyjaśniono kontrolę RBAC specyficzną dla aplikacji. Aby uzyskać informacje na temat implementowania kontroli dostępu opartej na rolach aplikacji, zobacz How to add app roles to your application and receive them in the token (Jak dodać role aplikacji do aplikacji i odbierać je w tokenie).

Definicje ról

Kontrola dostępu oparta na rolach to popularny mechanizm wymuszania autoryzacji w aplikacjach. Gdy organizacja używa kontroli dostępu opartej na rolach, deweloper aplikacji definiuje role, a nie autoryzuje poszczególnych użytkowników lub grup. Administrator może następnie przypisywać role różnym użytkownikom i grupom, aby kontrolować, kto ma dostęp do zawartości i funkcji.

Kontrola dostępu oparta na rolach ułatwia deweloperowi aplikacji zarządzanie zasobami i ich użyciem. Kontrola dostępu oparta na rolach umożliwia deweloperowi aplikacji kontrolowanie obszarów aplikacji, do których użytkownicy mogą uzyskiwać dostęp. Administracja istratory mogą kontrolować, którzy użytkownicy mają dostęp do aplikacji przy użyciu Wymagana właściwość przypisania użytkownika. Deweloperzy muszą uwzględnić określonych użytkowników w aplikacji i to, co użytkownicy mogą zrobić w aplikacji.

Deweloper aplikacji najpierw tworzy definicję roli w sekcji rejestracji aplikacji w centrum administracyjnym firmy Microsoft Entra. Definicja roli zawiera wartość zwracaną dla użytkowników, którzy są przypisani do tej roli. Deweloper może następnie użyć tej wartości do zaimplementowania logiki aplikacji w celu określenia, co ci użytkownicy mogą lub nie mogą zrobić w aplikacji.

Opcje kontroli dostępu opartej na rolach

Podczas rozważania włączenia autoryzacji kontroli dostępu opartej na rolach w aplikacji należy zastosować następujące wskazówki:

  • Zdefiniuj role wymagane do autoryzacji aplikacji.
  • Zastosuj, zapisz i pobierz odpowiednie role dla uwierzytelnionych użytkowników.
  • Określ zachowanie aplikacji na podstawie ról przypisanych do bieżącego użytkownika.

Po zdefiniowaniu ról Platforma tożsamości Microsoft obsługuje kilka różnych rozwiązań, których można użyć do stosowania, przechowywania i pobierania informacji o roli dla uwierzytelnionych użytkowników. Te rozwiązania obejmują role aplikacji, grupy firmy Microsoft Entra i korzystanie z niestandardowych magazynów danych na potrzeby informacji o rolach użytkownika.

Deweloperzy mają elastyczność zapewniania własnej implementacji sposobu interpretowania przypisań ról jako uprawnień aplikacji. Ta interpretacja uprawnień może obejmować używanie oprogramowania pośredniczącego lub innych opcji udostępnianych przez platformę aplikacji lub powiązanych bibliotek. Aplikacje zazwyczaj otrzymują informacje o roli użytkownika jako oświadczenia, a następnie decydują o uprawnieniach użytkowników na podstawie tych oświadczeń.

Role aplikacji

Microsoft Entra ID umożliwia definiowanie ról aplikacji dla aplikacji i przypisywanie tych ról do użytkowników i innych aplikacji. Role przypisywane do użytkownika lub aplikacji definiują ich poziom dostępu do zasobów i operacji w aplikacji.

Gdy identyfikator entra firmy Microsoft wystawia token dostępu dla uwierzytelnionego użytkownika lub aplikacji, zawiera nazwy ról przypisanych do jednostki (użytkownika lub aplikacji) w oświadczeniu tokenu roles dostępu. Aplikacja, taka jak internetowy interfejs API, który odbiera ten token dostępu w żądaniu, może następnie podejmować decyzje dotyczące autoryzacji na podstawie wartości w oświadczeniu roles .

Grupy

Deweloperzy mogą również używać grup Entra firmy Microsoft do implementowania kontroli dostępu opartej na rolach w swoich aplikacjach, gdzie członkostwo użytkownika w określonych grupach jest interpretowane jako ich członkostwo w rolach. Gdy organizacja używa grup, token zawiera oświadczenie grup. Oświadczenie grupy określa identyfikatory wszystkich przypisanych grup użytkownika w dzierżawie.

Ważne

Podczas pracy z grupami deweloperzy muszą pamiętać o koncepcji oświadczenia nadwyżkowego. Domyślnie, jeśli użytkownik jest członkiem więcej niż limit nadwyżkowy (150 dla tokenów SAML, 200 dla tokenów JWT, 6 w przypadku korzystania z niejawnego przepływu), identyfikator Entra firmy Microsoft nie emituje oświadczenia grup w tokenie. Zamiast tego zawiera ona "oświadczenie nadwyżkowe" w tokenie wskazującym, że użytkownik tokenu musi wysłać zapytanie do interfejsu API programu Microsoft Graph w celu pobrania członkostwa w grupach użytkownika. Aby uzyskać więcej informacji na temat pracy z oświadczeniami nadwyżkowymi, zobacz Oświadczenia w tokenach dostępu. Można emitować tylko grupy przypisane do aplikacji, chociaż przypisanie oparte na grupach wymaga wydania Microsoft Entra ID P1 lub P2.

Niestandardowy magazyn danych

Role aplikacji i grupy przechowują informacje o przypisaniach użytkowników w katalogu Microsoft Entra. Inną opcją zarządzania informacjami o roli użytkownika, które są dostępne dla deweloperów, jest utrzymywanie informacji poza katalogiem w niestandardowym magazynie danych. Na przykład w bazie danych SQL, usłudze Azure Table Storage lub usłudze Azure Cosmos DB dla tabel.

Korzystanie z magazynu niestandardowego umożliwia deweloperom dodatkowe dostosowanie i kontrolę nad sposobem przypisywania ról do użytkowników i sposobu ich reprezentowania. Jednak dodatkowa elastyczność wprowadza również większą odpowiedzialność. Na przykład nie ma obecnie dostępnego mechanizmu dołączania tych informacji do tokenów zwracanych z identyfikatora Entra firmy Microsoft. Aplikacje muszą pobierać role, jeśli informacje o rolach są przechowywane w niestandardowym magazynie danych. Pobieranie ról jest zwykle wykonywane przy użyciu punktów rozszerzalności zdefiniowanych w oprogramowania pośredniczącego dostępnego dla platformy używanej do tworzenia aplikacji. Deweloperzy są odpowiedzialni za prawidłowe zabezpieczanie niestandardowego magazynu danych.

Za pomocą zasad niestandardowych usługi Azure AD B2C można wchodzić w interakcje z niestandardowymi magazynami danych i dołączać oświadczenia niestandardowe w tokenie.

Wybieranie podejścia

Ogólnie rzecz biorąc, role aplikacji są zalecanym rozwiązaniem. Role aplikacji zapewniają najprostszy model programowania i są przeznaczone do implementacji kontroli dostępu opartej na rolach. Jednak określone wymagania aplikacji mogą wskazywać, że inne podejście byłoby lepszym rozwiązaniem.

Deweloperzy mogą używać ról aplikacji do kontrolowania, czy użytkownik może zalogować się do aplikacji, czy aplikacja może uzyskać token dostępu dla internetowego interfejsu API. Role aplikacji są preferowane w grupach firmy Microsoft entra przez deweloperów, gdy chcą opisać i kontrolować parametry autoryzacji w swoich aplikacjach. Na przykład aplikacja używająca grup do przerwania autoryzacji w następnej dzierżawie, ponieważ zarówno identyfikator grupy, jak i nazwa mogą być inne. Aplikacja korzystająca z ról aplikacji pozostaje bezpieczna.

Chociaż role aplikacji lub grupy mogą być używane do autoryzacji, kluczowe różnice między nimi mogą mieć wpływ na najlepsze rozwiązanie dla danego scenariusza.

Role aplikacji Grupy Microsoft Entra Niestandardowy magazyn danych
Model programowania Najprostsze. Są one specyficzne dla aplikacji i są zdefiniowane w rejestracji aplikacji. Przenoszą się z aplikacją. Bardziej złożone. Identyfikatory grup różnią się w zależności od dzierżaw i oświadczeń nadwyżkowych, które mogą być brane pod uwagę. Grupy nie są specyficzne dla aplikacji, ale dzierżawy firmy Microsoft Entra. Najbardziej złożone. Deweloperzy muszą zaimplementować środki, za pomocą których informacje o rolach są przechowywane i pobierane.
Wartości ról są statyczne między dzierżawami firmy Microsoft Entra Tak Nie. Zależy od implementacji.
Wartości ról mogą być używane w wielu aplikacjach Nie (chyba że konfiguracja roli jest duplikowana w każdej rejestracji aplikacji). Tak Tak
Informacje przechowywane w katalogu Tak Tak Nie.
Informacje są dostarczane za pośrednictwem tokenów Tak (oświadczenie ról) Tak (jeśli nadwyżka, oświadczenia grup mogą być pobierane w czasie wykonywania) Nie (pobrane w czasie wykonywania za pomocą kodu niestandardowego).
Okres istnienia Mieszka w rejestracji aplikacji w katalogu. Usunięto po usunięciu rejestracji aplikacji. Mieszka w katalogu. Pozostan bez zmian, nawet jeśli rejestracja aplikacji zostanie usunięta. Mieszka w niestandardowym magazynie danych. Nie jest powiązany z rejestracją aplikacji.

Następne kroki