Udostępnij za pośrednictwem

Uprawnienia i zgoda w punkcie końcowym usługi Azure Active Directory w wersji 1.0

  • Artykuł

Ostrzeżenie

Ta zawartość dotyczy starszego punktu końcowego Azure AD w wersji 1.0. Użyj Platforma tożsamości Microsoft dla nowych projektów.

Usługa Azure Active Directory (Azure AD) szeroko wykorzystuje użycie uprawnień dla przepływów OAuth i OIDC (OpenID Connect). Po odebraniu przez aplikację tokenu dostępu od usługi Azure AD aplikacja uwzględnia oświadczenia z opisami uprawnień, które aplikacja ma w odniesieniu do określonego zasobu.

Uprawnienia, znane również jako zakresy, ułatwiają autoryzację zasobu, ponieważ zasób musi tylko sprawdzić, czy token zawiera odpowiednie uprawnienia dla dowolnego interfejsu API, który wywołuje aplikacja.

Typy uprawnień

W usłudze Azure AD zdefiniowano dwa rodzaje uprawnień:

  • Uprawnienia delegowane — są używane przez aplikacje, w których użytkownik jest obecnie zalogowany. W przypadku takich aplikacji zgodę na uprawnienia żądane przez aplikację może wyrazić użytkownik lub administrator. Podczas wywołań interfejsu API do aplikacji są delegowane uprawnienia do działania w roli zalogowanego użytkownika. W zależności od interfejsu API użytkownik może nie być w stanie wyrazić zgody bezpośrednio na interfejs API i zamiast tego będzie wymagać od administratora udzielenia "zgody administratora".
  • Uprawnienia aplikacji — są używane przez aplikacje i nie wymagają zalogowanego użytkownika. Są to np. aplikacje działające jako usługi w tle lub demony. Uprawnienia aplikacji mogą być wyrażane tylko przez administratorów , ponieważ są one zwykle zaawansowane i umożliwiają dostęp do danych w granicach użytkownika lub danych, które w przeciwnym razie byłyby ograniczone do administratorów. Użytkownicy, którzy są zdefiniowani jako właściciele aplikacji zasobów (tj. interfejs API, który publikuje uprawnienia), mogą również udzielać uprawnień aplikacji dla własnych interfejsów API.

Czynne uprawnienia to uprawnienia, które aplikacja będzie posiadać podczas wysyłania żądań do interfejsu API.

  • W przypadku uprawnień delegowanych czynne uprawnienia aplikacji będą najmniejszą wspólną częścią delegowanych uprawnień przyznanych aplikacji (poprzez wyrażenie zgody) oraz uprawnień aktualnie zalogowanego użytkownika. Aplikacja nigdy nie może mieć większych uprawnień niż zalogowany użytkownik. Uprawnienia zalogowanego użytkownika mogą być określone w organizacji na podstawie zasad lub członkostwa w co najmniej jednej roli administratora. Aby dowiedzieć się, które role administratora mogą wyrazić zgodę na uprawnienia delegowane, zobacz Uprawnienia roli administratora w Azure AD. Załóżmy na przykład, że aplikacja ma przyznane uprawnienie delegowane User.ReadWrite.All w programie Microsoft Graph. Uprawnienie to przyznaje aplikacji nominalne uprawnienia do odczytu i aktualizowania profilu każdego użytkownika w organizacji. Jeśli zalogowany użytkownik jest administratorem globalnym, aplikacja będzie mogła zaktualizować profil każdego użytkownika w organizacji. Jednak jeśli zalogowany użytkownik nie ma roli administratora, aplikacja będzie mogła aktualizować tylko profil zalogowanego użytkownika. Użytkownik nie będzie mógł zaktualizować profili innych użytkowników w organizacji, ponieważ użytkownik mający uprawnienia do działania w imieniu innych osób nie ma odpowiednich uprawnień.
  • W przypadku uprawnień aplikacji efektywne uprawnienia aplikacji są na poziomie przywilejów wynikających z uprawnień. Na przykład aplikacja, która ma uprawnienie aplikacji User.ReadWrite.All, może aktualizować profile każdego użytkownika w organizacji.

Atrybuty uprawnień

Uprawnienia w usłudze Azure AD mają wiele właściwości, które pomagają użytkownikom, administratorom i deweloperom aplikacji w podejmowaniu świadomych decyzji dotyczących przydzielania uprawnień.

Uwaga

W witrynie Azure Portal i programie PowerShell można wyświetlić uprawnienia udostępniane przez aplikację usługi Azure AD lub Service Principal. Uruchom ten skrypt, aby wyświetlić uprawnienia udostępniane przez program Microsoft Graph.

Connect-AzureAD

# Get OAuth2 Permissions/delegated permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").OAuth2Permissions

# Get App roles/application permissions
(Get-AzureADServicePrincipal -filter "DisplayName eq 'Microsoft Graph'").AppRoles
Nazwa właściwości Opis Przykład
ID Wartość identyfikatora GUID, która unikatowo identyfikuje to uprawnienie. 570282fd-fa5c-430d-a7fd-fc8dc98a9dca
IsEnabled Wskazuje, czy to uprawnienie jest dostępne do użycia. true
Type Wskazuje, czy to uprawnienie wymaga zgody użytkownika, czy też zgody administratora. Użytkownik
AdminConsentDescription Opis widziany przez administratorów podczas procesu wyrażania przez nich zgody Zezwala aplikacji na odczytywanie wiadomości e-mail w skrzynkach pocztowych użytkowników.
AdminConsentDisplayName Przyjazna nazwa widziana przez administratorów podczas procesu wyrażania przez nich zgody. Odczytuj pocztę użytkownika
UserConsentDescription Opis widziany przez użytkowników podczas procesu wyrażania przez nich zgody. Zezwala aplikacji na odczytywanie wiadomości e-mail w skrzynce pocztowej użytkownika.
UserConsentDisplayName Przyjazna nazwa widziana przez użytkowników podczas procesu wyrażania przez nich zgody. Odczytywanie wiadomości
Value Ciąg, który służy do identyfikowania uprawnienia podczas przepływów autoryzacji OAuth 2.0. Ciąg Value można również być połączyć z ciągiem identyfikatora URI aplikacji w celu utworzenia nazwy FQDN uprawnień. Mail.Read

Przy uzyskiwaniu dostępu do niezbędnych zasobów lub interfejsów API aplikacje w usłudze Azure AD muszą uzyskać zgodę. Istnieje wiele rodzajów zgody, które powinny być znane aplikacji, aby jej praca zakończyła się pomyślnie. Podczas definiowania uprawnień należy także znać sposoby używane przez użytkowników podczas uzyskiwania dostępu do Twojej aplikacji lub interfejsu API.

  • Statyczna zgoda użytkownika — zachodzi automatycznie podczas przepływu autoryzacji OAuth 2.0 po podaniu zasobu, z którym chce współdziałać Twoja aplikacja. W scenariuszu statycznej zgody użytkownika aplikacja musi już znać wszystkie uprawnienia, które są niezbędne do skonfigurowania aplikacji w witrynie Azure Portal. Jeśli użytkownik (lub administrator, zależnie od potrzeb) nie udzielił zgody dla tej aplikacji, wtedy usługa Azure AD będzie monitować użytkownika o zgodę.

    Dowiedz się więcej o rejestrowaniu aplikacji usługi Azure AD, która żąda dostępu do statycznego zestawu interfejsów API.

  • Dynamiczna zgoda użytkownika — jest to funkcja dostępna w modelu aplikacji usługi Azure AD w wersji 2. W tym scenariuszu aplikacja żąda zbioru uprawnień, których potrzebuje w przepływie autoryzacji OAuth 2.0 dla aplikacji v2. Jeśli użytkownik nie wyraził jeszcze zgody, w tym momencie zostanie wyświetlony monit o jej wyrażenie. Dowiedz się więcej na temat dynamicznej zgody.

    Ważne

    Dynamiczne udzielanie zgody może być wygodne, ale stanowi duże wyzwanie w przypadku uprawnień wymagających zgody administratora, ponieważ w momencie wyrażania zgody administrator nie dysponuje informacjami dotyczącymi uprawnień. Jeśli potrzebujesz uprawnień administratora uprzywilejowanych lub jeśli aplikacja używa dynamicznej zgody, musisz zarejestrować wszystkie uprawnienia w Azure Portal (a nie tylko podzestaw uprawnień, które wymagają zgody administratora). Dzięki temu administratorzy dzierżawy mogą wyrazić zgodę w imieniu wszystkich użytkowników.

  • Zgoda administratora — jest wymagana, gdy aplikacja potrzebuje dostępu do niektórych uprawnień wysokiego poziomu. Zgoda administratora zapewnia, że administratorzy mają dodatkową kontrolę nad autoryzowaniem dostępu aplikacji lub użytkowników do danych organizacji wymagających szczególnych uprawnień. Dowiedz się więcej na temat sposobu udzielania zgody administratora.

Najlepsze rozwiązania

Najlepsze rozwiązania klientów

  • Żądaj tylko tych uprawnień, których potrzebuje Twoja aplikacja. Aplikacje ze zbyt dużą liczbą uprawnień niosą ze sobą ryzyko ujawnienia danych użytkowników w przypadku naruszenia bezpieczeństwa aplikacji.
  • Wybierz między uprawnieniami delegowanymi i uprawnieniami aplikacji, biorąc pod uwagę scenariusz obsługiwany przez aplikację.
    • Zawsze używaj uprawnień delegowanych, jeśli wywołanie jest wykonywane w imieniu użytkownika.
    • Uprawnień aplikacji używaj tylko wtedy, jeśli aplikacja jest nieinterakcyjna i nie wykonuje wywołań w imieniu żadnego określonego użytkownika. Uprawnienia aplikacji są wysoce uprzywilejowane i należy ich używać tylko w razie absolutnej konieczności.
  • W przypadku używania aplikacji opartej na punkcie końcowym w wersji 2.0 zawsze konfiguruj uprawnienia statyczne (określone w rejestracji aplikacji) tak, aby były nadzbiorem uprawnień dynamicznych, żądanych w czasie wykonywania (są to uprawnienia określone w kodzie i wysyłane jako parametry zapytania w żądaniu autoryzacji), aby scenariusze, takie jak zgoda administratora, działały poprawnie.

Najlepsze rozwiązania dotyczące zasobów/interfejsu API

  • Zasoby, które udostępniają interfejsy API, powinny szczegółowo definiować uprawnienia dla chronionych przez nie danych lub akcji. Dzięki zastosowaniu tego najlepszego rozwiązania klienci nie otrzymują uprawnień do niepotrzebnych danych oraz są poinformowani, do jakich danych mają dostęp.
  • Zasoby powinny w sposób jawny osobno definiować uprawnienia Read i ReadWrite.
  • Zasoby powinny oznaczyć wszystkie uprawnienia umożliwiające dostęp do danych przekraczający granice użytkownika jako uprawnienia Admin.
  • Nazwy zasobów powinny być zgodne ze wzorcem Subject.Permission[.Modifier], gdzie:

    • Subject odpowiada typowi dostępnych danych

    • Permission odpowiada akcji, którą użytkownik może wykonać na tych danych

    • Modifier jest używany opcjonalnie do opisywania specjalizacji innego uprawnienia

      Na przykład:

    • Mail.Read — umożliwia użytkownikom odczytywanie wiadomości e-mail.

    • Mail.ReadWrite — umożliwia użytkownikom odczytywanie i pisanie wiadomości e-mail.

    • Mail.ReadWrite.All — umożliwia administratorowi lub użytkownikom dostęp do wszystkich wiadomości w organizacji.