Udostępnij za pośrednictwem

Dostosowywanie tokenów

Jako deweloper, Twoja podstawowa interakcja z Microsoft Entra ID polega na żądaniu tokenu, aby zidentyfikować użytkownika. Żądasz również tokenu w celu uzyskania autoryzacji w celu wywołania internetowego interfejsu API. Token internetowego interfejsu API określa, co ten interfejs API może zrobić, gdy obsługuje określone żądanie. W tym artykule dowiesz się więcej o informacjach, które można otrzymywać w tokenach i sposobach dostosowywania tokenów. Te najlepsze rozwiązania dla deweloperów Zero Trust zwiększają elastyczność i kontrolę, jednocześnie zwiększając bezpieczeństwo aplikacji z najmniejszymi uprawnieniami.

Przyczyny dostosowywania tokenów aplikacji zależą od procesu używanego do zwiększenia szczegółowości autoryzacji w aplikacjach i interfejsach API. Na przykład w aplikacji mogą istnieć różne role użytkownika, poziomy dostępu i funkcje, które opierają się na informacjach z tokenów.

Interfejs API programu Microsoft Graph udostępnia niezawodny zestaw informacji o katalogu i danych na platformie Microsoft 365. Możesz opracować precyzyjny i rozbudowany system autoryzacji, tworząc dane w programie Microsoft Graph. Na przykład możesz uzyskać dostęp do informacji z członkostwa w grupie użytkownika, szczegółowych danych profilu, programu SharePoint i programu Outlook do użycia w decyzjach dotyczących autoryzacji. Dane autoryzacji można uwzględnić w tokenie z identyfikatora Entra firmy Microsoft.

Autoryzacja na poziomie aplikacji

Dział IT może dodać autoryzację na poziomie aplikacji bez dostosowywania tokenu lub dodawania kodu.

Specjaliści IT mogą uniemożliwić wydawanie tokenów dla dowolnej aplikacji w dzierżawie przy użyciu flagi 'wymagane przypisanie użytkownika'. Takie podejście gwarantuje, że tylko zestaw użytkowników może zalogować się do aplikacji. Bez tej flagi wszyscy użytkownicy w dzierżawie mogą uzyskiwać dostęp do aplikacji. Za pomocą tej flagi tylko przypisani użytkownicy i grupy mogą uzyskiwać dostęp do aplikacji. Gdy przypisany użytkownik uzyskuje dostęp do aplikacji, aplikacja otrzymuje token. Jeśli użytkownik nie ma przydziału, aplikacja nie otrzyma tokenu. Pamiętaj, aby zawsze łagodnie obsługiwać żądania tokenów, które nie otrzymują tokenów.

Metody dostosowywania tokenu

Istnieją dwa sposoby dostosowywania tokenów: opcjonalne żądania i mapowanie żądań.

Opcjonalne oświadczenia

Opcjonalne roszczenia określają, które roszczenia chcesz, aby Microsoft Entra ID przesyłał do Twojej aplikacji w tokenach. Możesz użyć opcjonalnych oświadczeń, aby:

  • Wybierz więcej atrybutów do umieszczenia w tokenach aplikacji.
  • Zmień sposób, w jaki platforma tożsamości firmy Microsoft zwraca oświadczenia w tokenach.
  • Dodawać oświadczenia niestandardowe dla aplikacji i uzyskiwać do nich dostęp.

Opcjonalne roszczenia są dołączone do obiektu rejestracji aplikacji z określonym schematem. Mają zastosowanie do aplikacji niezależnie od tego, gdzie była uruchomiona. Podczas pisania aplikacji wielodostępnej opcjonalne oświadczenia działają dobrze, ponieważ są one spójne dla każdego dzierżawcy w usłudze Microsoft Entra ID. Na przykład adres IP nie jest charakterystyczny dla dzierżawy, natomiast aplikacja ma swój adres IP.

Domyślnie użytkownicy-goście w dzierżawie mogą również logować się do aplikacji. Jeśli chcesz zablokować użytkowników-gości, należy wyrazić zgodę na opcjonalne oświadczenie (acct). Jeśli 1, to użytkownik ma klasyfikację gościa. Jeśli chcesz zablokować gości, zablokuj tokeny za pomocą polecenia acct==1.

Zasady mapowania oświadczeń

W usłudze Microsoft Entra ID obiekty zasad reprezentują zestawy reguł dla poszczególnych aplikacji lub wszystkich aplikacji w organizacji. Zasady mapowania oświadczeń modyfikują oświadczenia, które Microsoft Entra ID wystawia w tokenach dla określonych aplikacji.

Mapowanie roszczeń jest stosowane do informacji specyficznych dla najemcy, które nie mają ustalonego schematu (na przykład EmployeeID, DivisionName). Mapowanie oświadczeń ma zastosowanie na poziomie jednostki usługi, który kontroluje administrator dzierżawy. Mapowanie roszczeń odpowiada aplikacji korporacyjnej lub głównej jednostce usługi aplikacji. Każda dzierżawa może mieć własne mapowanie roszczeń.

Podczas tworzenia aplikacji liniowej biznesowej zwróć szczególną uwagę na to, co robi Twój tenant (jakie konkretne atrybuty Twój tenant ma dostępne, które można użyć w tokenie). Jeśli na przykład organizacja ma właściwość nazwy działu użytkownika (a nie standardowe pole w identyfikatorze Entra firmy Microsoft) w lokalnej usłudze Active Directory, użyj programu Microsoft Entra Connect , aby zsynchronizować ją z identyfikatorem Entra firmy Microsoft.

Aby zawierać te informacje, użyj jednego ze standardowych atrybutów rozszerzenia. Zdefiniuj swój token, używając oświadczenia dotyczącego nazwy działu, które można skonstruować na podstawie odpowiadającego mu rozszerzenia (nawet jeśli nie ma zastosowania do każdego dzierżawcy). Na przykład organizacja umieszcza nazwę działu w atrybucie rozszerzenia 13.

Za pomocą mapowania twierdzeń można sprawić, że będzie działać dla innej dzierżawy, która przypisuje nazwę podziału w atrybucie siedem.

Planowanie dostosowywania tokenu

Dostosowany token zależy od typu aplikacji: aplikacji klienckiej lub interfejsu API. Nie ma różnicy w tym, co można zrobić, aby dostosować token. To, co można włożyć w token, jest takie samo dla każdego z nich. Token, który wybierzesz do dostosowania, zależy od tokenu używanego przez aplikację.

Dostosowywanie tokenów identyfikatorów

Jeśli tworzysz aplikację kliencką, dostosujesz token identyfikatora , ponieważ jest to token, którego żądasz, aby zidentyfikować użytkownika. Token należy do aplikacji, gdy oświadczenie odbiorców (aud) w tokenie jest zgodne z identyfikatorem klienta aplikacji. W przypadku aplikacji klienckiej, która wywołuje interfejsy API, ale nie implementuje ich, upewnij się, że dostosowano tylko token identyfikatora aplikacji.

Witryna Azure Portal i interfejs API programu Microsoft Graph umożliwiają dostosowanie tokenu dostępu dla aplikacji, ale te dostosowania nie mają wpływu. Nie można dostosować tokenu dostępu dla interfejsu API, którego nie jesteś właścicielem. Pamiętaj, że aplikacja nie może próbować dekodować ani sprawdzać tokenu dostępu, który aplikacja kliencka otrzymuje jako autoryzację w celu wywołania interfejsu API.

Dostosowywanie tokenów dostępu

Podczas tworzenia interfejsu API dostosowujesz token dostępu , ponieważ interfejs API odbiera tokeny dostępu w ramach wywołania klienta do interfejsu API.

Aplikacje klienckie zawsze dostosowują token tożsamości, który odbierają, do tożsamości użytkownika. Interfejsy API dostosowują tokeny dostępu, które są częścią procesu wywołania API.

Grupy i role aplikacji

Jedną z najpopularniejszych technik autoryzacji jest oparcie dostępu do członkostwa w grupie użytkownika lub przypisanych ról. Konfigurowanie roszczeń grupowych i ról aplikacji w tokenach pokazuje, jak skonfigurować aplikacje z wykorzystaniem definicji ról aplikacji oraz jak przypisać grupy zabezpieczeń do konkretnych ról aplikacji. Te metody pomagają zwiększyć elastyczność i kontrolę przy jednoczesnym zwiększeniu zabezpieczeń Zero Trust aplikacji zgodnie z zasadą najmniejszych uprawnień.

Następne kroki

  • Last updated on