Udostępnij za pośrednictwem

Konfigurowanie roszczeń grupowych i ról aplikacji w tokenach

  • Artykuł

Ten artykuł ułatwia konfigurowanie aplikacji przy użyciu definicji ról aplikacji i przypisywanie grup zabezpieczeń do ról aplikacji, dzięki czemu można zwiększyć elastyczność i kontrolę przy jednoczesnym zwiększeniu zabezpieczeń aplikacji o najniższych uprawnieniach.

Identyfikator Entra firmy Microsoft obsługuje wysyłanie przypisanych grup zabezpieczeń użytkownika, ról katalogu Microsoft Entra i grup dystrybucyjnych jako oświadczeń w tokenie. Tego podejścia można użyć do kierowania autoryzacją w aplikacjach. Jednak obsługa grup identyfikatorów Entra firmy Microsoft w tokenie jest ograniczona przez rozmiar tokenu. Gdy użytkownik jest członkiem zbyt wielu grup, nie ma żadnych grup w tokenie.

W tym artykule przedstawiono alternatywne podejście do uzyskiwania informacji o użytkowniku w tokenach przy użyciu obsługi grup Firmy Microsoft Entra. Zamiast tego skonfigurujesz aplikacje przy użyciu definicji ról aplikacji i przypiszesz grupy do ról aplikacji. To zero trust najlepszych rozwiązań dla deweloperów zwiększa elastyczność i kontrolę, jednocześnie zwiększenie zabezpieczeń aplikacji z najniższymi uprawnieniami.

Możesz skonfigurować roszczenia grupowe w tokenach, które możesz używać w aplikacjach do autoryzacji. Pamiętaj, że informacje o grupie w tokenie są aktualne tylko wtedy, gdy otrzymasz token. Oświadczenia grupy obejmują wspieranie dwóch głównych wzorców.

  • Grupy zidentyfikowane przez atrybut identyfikatora obiektu (OID) w Microsoft Entra.
  • Grupy zidentyfikowane przez atrybut sAMAccountName lub GroupSID dla grup i użytkowników synchronizowanych z usługą Active Directory.

Członkostwo w grupie może prowadzić do podejmowania decyzji dotyczących autoryzacji. W poniższym przykładzie przedstawiono niektóre oświadczenia w tokenie. Możesz dodać uprawnienia i role grup do tokenów ID lub tokenów dostępu.

"aud": "00001111-aaaa-2222-bbbb-3333cccc4444", 
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0", 
"iat": 1669657224, "nbf": 1669657224, "exp": 1669661124, 
"groups": [ 
   "0760b6cf-170e-4a14-91b3-4b78e0739963", 
   "3b2b0c93-acd8-4208-8eba-7a48db1cd4c0" 
 ],
"oid": "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "bbbbcccc-1111-dddd-2222-eeee3333ffff", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

Tablica groups claims składa się z identyfikatorów grup, do których należy ten użytkownik. Tablica wids składa się z identyfikatorów ról Microsoft Entra przypisanych do tego użytkownika. W tym miejscu cf1c38e5-3621-4004-a7cb-879624dced7c pokazuje, że przypisane role tego użytkownika obejmują dewelopera aplikacji i standardowego członka, co wskazuje 3b2b0c93-acd8-4208-8eba-7a48db1cd4c0.

Aplikacja może podejmować decyzje dotyczące autoryzacji na podstawie obecności lub braku tych oświadczeń i ich wartości. Zobacz wbudowane role firmy Microsoft, aby uzyskać listę wartości oświadczenia wids.

Aby dodać oświadczenia i do tokenów, wybierz pozycję Wszystkie grupy, jak pokazano w poniższym przykładzie na ekranie rejestracji aplikacjiKonfiguracja tokenuOpcjonalne oświadczeniaEdytowanie oświadczeń grup.

Zrzut ekranu ekranu Edytowanie roszczeń grupowych pokazuje wybrane typy grup: grupy przypisane do aplikacji.

Nadwyżki grupowe

Jeśli zażądasz wszystkich grup w tokenie, jak pokazano w powyższym przykładzie, nie można zakładać, że token będzie zawierał klauzulę groups. Istnieją limity rozmiaru tokenów i na oświadczeniach groups, aby nie stały się zbyt duże. Gdy użytkownik jest członkiem zbyt wielu grup, aplikacja musi uzyskać członkostwo w grupie użytkownika z programu Microsoft Graph. Limity dla grup w roszczeniu groups są następujące:

  • 200 grup dla tokenów internetowych JSON (JWT).
  • 150 grup tokenów języka SAML (Security Assertion Markup Language).
  • Sześć grup podczas korzystania z niejawnego przepływu (na przykład przy użyciu ASP.NET Core, który pobiera tokeny identyfikacyjne za pośrednictwem niejawnej części przepływu hybrydowego).
    • Przepływ niejawny nie jest już zalecany w przypadku aplikacji internetowych jednostronicowych.
    • Niejawny przepływ może być używany w aplikacjach internetowych tylko dla tokenu identyfikatora, nigdy tokenu dostępu, w przepływie hybrydowym OAuth2.

Jeśli używasz protokołu OpenID Connect lub OAuth2, możesz mieć maksymalnie 200 grup w tokenie. Jeśli używasz protokołu SAML, możesz mieć tylko 150 grup, ponieważ tokeny SAML są większe niż tokeny protokołu OAuth2 i OpenID Connect. Jeśli używasz przepływu niejawnego, limit wynosi sześć, ponieważ te odpowiedzi są wyświetlane w adresie URL. We wszystkich tych przypadkach zamiast oświadczenia groups zobaczysz wskazanie (znane jako nadwyżka grupy), które informuje, że użytkownik jest członkiem zbyt wielu grup, aby zmieścić się w tokenie.

Roszczenie groups powinno być mapowane na src1. Teoretycznie powinieneś wyszukać oświadczenie _claim_sources, a potem znaleźć członka src1. W tym miejscu znajdziesz zapytanie programu Graph, którego chcesz użyć do uzyskania członkostwa w grupie. Jednak występuje problem z tym, co widzisz w przykładowym zapytaniu programu Graph. Przechodzi on do usługi Azure AD Graph (która jest wycofywana przez Microsoft), więc nie używaj go.

Ukryte wskazanie nadwyżki przepływu jest realizowane za pomocą roszczenia hasgroups zamiast roszczenia groups.

Aby zapewnić właściwą autoryzację przy użyciu członkostwa w grupie, sprawdź, czy Twoja aplikacja weryfikuje oświadczenie groups. Jeśli istnieje, użyj tego oświadczenia, aby określić członkostwo użytkownika w grupie. Jeśli nie ma roszczenia groups, sprawdź istnienie roszczenia hasgroups lub roszczenia _claim_names z członkiem groups w tablicy. Jeśli istnieją jeden z tych oświadczeń, użytkownik jest członkiem zbyt wielu grup tokenu. W takim przypadku aplikacja musi używać programu Microsoft Graph, aby określić członkostwo w grupie dla użytkownika. Zobacz Listę członkostw użytkownika (bezpośrednich i przechodnich), aby znaleźć wszystkie grupy, zarówno bezpośrednie, jak i przechodnie, do których należy użytkownik.

Jeśli aplikacja wymaga informacji o członkostwie w grupach w czasie rzeczywistym, użyj programu Microsoft Graph, aby określić członkostwo w grupie. Pamiętaj, że informacje otrzymanego tokenu są aktualne tylko w momencie uzyskania tokenu.

Zapoznaj się z poniższym przykładem Rejestracje aplikacji | Konfiguracja tokenu | Opcjonalne oświadczenia | Edytowanie oświadczeń grup ekranu. Jednym ze sposobów uniknięcia trafienia oświadczenia nadwyżkowego grupy jest wybranie grupy grupy przypisane do aplikacji na ekranie Edytuj grupy oświadczenia zamiast Wszystkie grupy.

Zrzut ekranu ekranu edycji oświadczeń grupy pokazuje wybrane typy grup: grupy zabezpieczeń, role katalogu i wszystkie grupy.

Po wybraniu grup przypisanych do aplikacji, grupa zostanie uwzględniona w roszczeniu groups, jeśli spełnione są następujące warunki:

  • grupa jest przypisana do aplikacji dla przedsiębiorstw
  • użytkownik jest bezpośrednim członkiem grupy

Na dzień publikacji tego artykułu, grupy przypisane do opcji aplikacji nie obsługują członkostwa pośredniego. Przypisanie grupy wymaga co najmniej licencji na poziomie P1. Bezpłatny najemca nie może przypisywać grup do aplikacji.

Grupy i role aplikacji

Innym sposobem uniknięcia problemu z przekroczeniem limitu grupy jest zdefiniowanie ról aplikacji, które zezwalają na uwzględnianie użytkowników i grup jako typów członków. Jak pokazano w poniższym przykładzie ekranu Rejestracje aplikacji | Role aplikacji | Tworzenie roli aplikacji, wybierz Użytkownicy/grupy dla Dozwolone typy członków.

Zrzut ekranu ekranu Tworzenie roli aplikacji pokazuje dozwolone typy członków: Użytkownicy/Grupy.

Po utworzeniu roli aplikacji wrejestracji aplikacji, specjalista IT może przypisać użytkowników i grupy do roli. Aplikacja otrzymuje roszczenie roles w swoim tokenie (token ID dla aplikacji, token dostępu dla interfejsów API) ze wszystkimi przypisanymi rolami zalogowanego użytkownika, jak pokazano w poniższym przykładzie.

"aud": "11112222-bbbb-3333-cccc-4444dddd5555",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "bbbbbbbb-1111-2222-3333-cccccccccccc",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "ccccdddd-2222-eeee-3333-ffff4444aaaa",

Pamiętaj, aby aplikacja obsługiwała następujące warunki:

  • brak roszczenia roles
  • użytkownik nie ma przypisania roli
  • wiele wartości w oświadczeniu roles, kiedy użytkownik ma więcej niż jeden przydział roli

Podczas tworzenia ról aplikacji, które zezwalają użytkownikom i grupom na członkostwo, zawsze definiuj podstawową rolę użytkownika bez ról autoryzacji z podwyższonym poziomem uprawnień. Jeśli konfiguracja aplikacji dla przedsiębiorstw wymaga przypisania, tylko użytkownicy z bezpośrednim przypisaniem do aplikacji lub członkostwa w grupie przypisanej do aplikacji mogą używać aplikacji.

Jeśli aplikacja ma zdefiniowane role aplikacji, które zezwalają użytkownikom i grupom jako członkom, po przypisaniu użytkownika lub grupy do aplikacji jedna z zdefiniowanych ról aplikacji musi być częścią przypisania użytkownika lub grupy do aplikacji. Jeśli aplikacja zdefiniowała tylko role z podwyższonym poziomem uprawnień (na przykład admin) dla aplikacji, wszyscy użytkownicy i grupy zostaną przypisani do roli administratora. Podczas definiowania roli podstawowej (takiej jak user) użytkownicy i grupy przypisane do aplikacji mogą mieć przypisaną podstawową rolę użytkownika.

Oprócz unikania nadwyżkowych roszczeń grup, kolejną zaletą korzystania z ról jest brak potrzeby mapowania identyfikatora lub nazwy grupy i jej znaczenia w aplikacji. Na przykład kod może wyszukać oświadczenie roli administratora zamiast iterować za pośrednictwem grup w oświadczeniach groups i decydować, które identyfikatory grup powinny być dozwolone przez funkcję administratora.

Weryfikowanie i używanie ról w kodzie

Podczas definiowania ról dla swojej aplikacji, twoim obowiązkiem jest zaimplementowanie logiki autoryzacji dla tych ról. Zobacz Implementowanie kontroli dostępu opartej na rolach w aplikacjach, aby dowiedzieć się, jak zaimplementować logikę autoryzacji w aplikacjach.

Następne kroki