Konfigurieren von Gruppenansprüchen und App-Rollen in Token

  • Artikel

In diesem Artikel können Sie Ihre Apps mit App-Rollendefinitionen konfigurieren und App-Rollen Sicherheitsgruppen zuweisen, sodass Sie Flexibilität und Kontrolle verbessern und gleichzeitig die Anwendungssicherheit mit geringsten Berechtigungen erhöhen können.

Microsoft Entra ID unterstützt das Senden von zugewiesenen Sicherheitsgruppen, Microsoft Entra-Verzeichnisrollen und Verteilergruppen als Ansprüche in einem Token. Sie können diesen Ansatz verwenden, um die Autorisierung in Apps zu fördern. Microsoft Entra ID beschränkt jedoch die Gruppenunterstützung in einem Token durch die Größe des Tokens. Wenn der Benutzer Mitglied von zu vielen Gruppen ist, gibt es keine Gruppen im Token.

In diesem Artikel lernen Sie einen alternativen Ansatz zum Abrufen von Benutzerinformationen in Token mithilfe des Microsoft Entra-Gruppensupports kennen. Stattdessen konfigurieren Sie Ihre Apps mit App-Rollendefinitionen und weisen App-Rollen Gruppen zu. Diese bewährte Methode für Zero Trust-Entwicklung verbessert Flexibilität und Kontrolle und erhöht gleichzeitig die Anwendungssicherheit mit geringsten Berechtigungen.

Sie können Gruppenansprüche in Token konfigurieren, die Sie in Ihren Anwendungen für die Autorisierung verwenden können. Denken Sie daran, dass Gruppeninformationen im Token nur aktuell sind, wenn Sie das Token empfangen. Gruppenansprüche unterstützen zwei Hauptmuster:

  • Gruppen, die durch das Attribut ihres Microsoft Entra-Objektbezeichners (OID) identifiziert werden.
  • Gruppen, die durch sAMAccountName oder GroupSID-Attribute für in Active Directory-synchronisierte Gruppen und Benutzer identifiziert werden.

Die Gruppenmitgliedschaft kann Autorisierungsentscheidungen fördern. Das folgende Beispiel zeigt einige Ansprüche in einem Token. Sie können Gruppenansprüche und Rollen entweder zu ID- oder Zugriffstoken hinzufügen.

"aud": "e18c04b1-4868-4b93-93d1-8d71f17ab99b", 
"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": "cb7eda1b-d09a-40ae-b8bb-37836ebc6abd",
"sub": "3OBtLXUC2ZrN_ADLNjW9X4o0lcd61py7lgHw3Skh77s",
"tid": "833ced3d-cb2e-41ce-92f1-29e2af035ddc", 
"ver": "2.0", 
"wids": [ 
   "cf1c38e5-3621-4004-a7cb-879624dced7c", 
   "b79fbf4d-3ef9-4689-8143-76b194e85509" 
 ]

Das groups Anspruchsarray besteht aus den IDs der Gruppen, in denen dieser Benutzer Mitglied ist. Das wids Array umfasst die IDs der Microsoft Entra-Rollen, die diesem Benutzer zugewiesen sind. Hier zeigt cf1c38e5-3621-4004-a7cb-879624dced7c, dass die zugewiesenen Rollen dieses Benutzers Anwendungsentwickler und Standardmitglied enthalten, wie 3b2b0c93-acd8-4208-8eba-7a48db1cd4c0 zeigt.

Ihre App kann Autorisierungsentscheidungen basierend auf dem Vorhandensein oder Fehlen dieser Ansprüche und deren Werte treffen. Sehen Sie in den integrierten Microsoft Entra-Rollen eine Liste der Werte für den wids Anspruch.

Wenn Sie groups und wids-Ansprüche Ihrem Token hinzufügen möchten, wählen Sie Alle Gruppen aus, wie im folgenden Beispiel der App-Registrierungen | Token-Konfiguration | Optionale Ansprüche | Gruppenansprüche bearbeiten angezeigt.

Screenshot des Bildschirms „Gruppenansprüche bearbeiten“, der ausgewählte Gruppentypen zeigt: Gruppen, die der Anwendung zugewiesen sind.

Gruppenübergänge

Wenn Sie alle Gruppen in Ihrem Token anfordern, wie im obigen Beispiel gezeigt, können Sie sich nicht darauf verlassen, dass das Token den groups Anspruch in Ihrem Token hat. Es gibt Größenbeschränkungen für Token und für groups Ansprüche, damit sie nicht zu groß werden. Wenn der Benutzer Mitglied von zu vielen Gruppen ist, muss Ihre App die Gruppenmitgliedschaft des Benutzers aus Microsoft Graph abrufen. Die Grenzwerte für Gruppen in einem groups Anspruch sind:

  • 200 Gruppen für JSON-Webtoken (JWT).
  • 150 Gruppen für SAML-Token (Security Assertion Markup Language).
  • 6 Gruppen bei Verwendung des impliziten Flusses (z. B. mithilfe des ASP.NET-Kerns, der ID-Token über den impliziten Flussteil eines Hybridflusses abruft).
    • Der implizite Fluss wird für Web-Apps mit einer Seite nicht mehr empfohlen.
    • In einem OAuth2-Hybridablauf kann ein impliziter Fluss nur in Web-Apps für das ID-Token verwendet werden, niemals das Zugriffstoken.

Wenn Sie OpenID Connect oder OAuth2 verwenden, können Sie bis zu 200 in Ihrem Token haben. Wenn Sie SAML verwenden, können Sie nur über 150 Gruppen verfügen, da SAML-Token größer als OAuth2- und OpenID Connect-Token sind. Wenn Sie den impliziten Fluss verwenden, beträgt der Grenzwert sechs, da diese Antworten in der URL angezeigt werden. In all diesen Fällen wird anstelle eines groups-Anspruchs ein Hinweis (als Gruppenüberlastung bezeichnet) angezeigt, der Sie informiert, dass der Benutzer Mitglied von zu vielen Gruppen ist, die in Ihr Token passen.

Im folgenden Tokenbeispiel gibt es für eine OpenID connect oder OAuth2 JSON-Webtoken (JWT) keinen groups-Anspruch, wenn der Benutzer Mitglied von zu vielen Gruppen ist. Stattdessen gibt es einen _claim_names-Anspruch, der ein groups-Element des Arrays enthält.

Screenshot des Beispieltokens zeigt die Abfrage.

Im obigen Token-Beispiel sehen Sie, dass der groups Anspruch zugeordnet src1 werden soll. Theoretisch suchen Sie dann nach dem _claim_sources Anspruch und dann suchen Sie das src1 Mitglied. Von dort aus finden Sie die Graph-Abfrage, die Sie zum Abrufen der Gruppenmitgliedschaft verwenden. Es gibt jedoch ein Problem mit dem, was Sie in der Beispieldiagrammabfrage sehen. Es wechselt zu Azure AD Graph (was bei Microsoft veraltet ist), also verwenden Sie es nicht.

Implizite Flussüberlastungsanzeige erfolgt mit einem hasgroups-Anspruch anstelle des groups-Anspruchs.

Um die ordnungsgemäße Autorisierung mithilfe der Gruppenmitgliedschaft sicherzustellen, überprüfen Sie, ob Ihre App den groups-Anspruch hat. Wenn vorhanden, verwenden Sie diesen Anspruch, um die Gruppenmitgliedschaft des Benutzers zu ermitteln. Wenn kein groups Anspruch vorhanden ist, überprüfen Sie, ob ein hasgroups Anspruch oder ein _claim_names Anspruch mit einem groups Element des Arrays vorhanden ist. Wenn eine dieser Ansprüche vorhanden ist, ist der Benutzer Mitglied von zu vielen Gruppen für das Token. In diesem Fall muss Ihre App Microsoft Graph verwenden, um die Gruppenmitgliedschaft für den Benutzer zu ermitteln. Siehe Auflisten der Mitgliedschaften eines Benutzers (direkt und transitiv), um alle Gruppen zu finden, sowohl direkt als auch transitiv, bei denen der Benutzer Mitglied ist.

Wenn Ihre Anwendung Informationen zur Gruppenmitgliedschaft in Echtzeit benötigt, verwenden Sie Microsoft Graph, um die Gruppenmitgliedschaft zu ermitteln. Denken Sie daran, dass die von Ihnen empfangenen Informationen nur zum Zeitpunkt des Abrufens des Tokens auf dem neuesten Stand sind.

Sehen Sie sich das folgende Beispiel für die App-Registrierungen | Token-Konfiguration | Optionale Ansprüche | Gruppenansprüche bearbeiten den Anspruchsbildschirm an. Eine Möglichkeit zum Vermeiden des Zugriffs auf einen Gruppenüberlastungsanspruch besteht darin, Gruppen auszuwählen, die der Anwendung auf dem „Gruppenanspruch bearbeiten“- Bildschirm anstelle von „Alle Gruppen“" zugewiesen sind.

Screenshot des Bildschirms „Gruppenansprüche bearbeiten“, der ausgewählte Gruppentypen zeigt: Sicherheitsgruppen, Verzeichnisrollen und alle Gruppen.

Wenn Sie Gruppen auswählen, die der Anwendung zugewiesen sind, wird eine Gruppe in den groups Anspruch eingeschlossen, wenn die folgenden Bedingungen erfüllt sind:

Ab der Veröffentlichung dieses Artikels unterstützen die Gruppen, die der Anwendungsoption zugewiesen sind, unterstützen keine indirekte Mitgliedschaft. Für die Gruppenzuweisung ist mindestens eine P1-Level-Lizenz erforderlich. Ein kostenloser Mandant kann einer Anwendung keine Gruppen zuweisen.

Gruppen- und App-Rollen

Eine weitere Möglichkeit, um das Gruppenüberlastungsproblem zu vermeiden, besteht darin, dass die App App-Rollen definiert, die Benutzern und Gruppen als Mitgliedertypen erlauben. Wie im folgenden Beispiel der App-Registrierungen | App-Rollen | App-Rollen erstellen auf dem Bildschirm gezeigt, wählen Sie Benutzer/Gruppen für zulässige Mitgliedstypen aus.

Screenshot des Bildschirms „App-Rollen erstellen“, der zulässige Mitgliedertypen zeigt: Benutzer/Gruppen.

Nach dem Erstellen der App-Rolle in der Registrierung der App können die IT-Profis der Rolle Benutzer und Gruppen zuweisen. Ihre App erhält einen roles-Anspruch in Ihrem Token (ID-Token für App, Zugriffstoken für APIs) mit allen zugewiesenen Rollen des angemeldeten Benutzers, wie im folgenden Tokenbeispiel gezeigt.

"aud": "acaf6ce9-81f0-462a-a93d-a314070738d3",
"iss": "https://login.microsoftonline.com/833ced3d-cb2e-41de-92f1-29e2af035ddc/v2.0",
"iat": 1670826509, "nbf": 1670826509, "exp": 1670830409,
"name": "Kyle Marsh",
"oid": "cb7eda1b-d09a-419e-b8bb-37836ebc6abd",
"preferred_username": "kylemar@idfordevs.dev",
"roles": [
 "Approver",
 "Reviewer" 
],
"sub": "dx-4lf-0loB3c3uVrULnZ2VTLuRRWYff0q7-QlIfYU4",
"tid": "833ced3d-cb3e-41de-92f1-29e2af035ddc",

Denken Sie daran, dass Ihre Anwendung die folgenden Bedingungen behandelt:

  • fehlender roles Anspruch
  • Benutzer hat keine Rollenzuweisung
  • mehrere Werte im roles-Anspruch, wenn der Benutzer mehrere Rollenzuweisungen hat

Wenn Sie App-Rollen erstellen, die Benutzer*innen und Gruppen als Mitglieder zulassen, müssen Sie immer eine grundlegende Benutzerrolle erstellen, die keine Rollen mit erhöhten Berechtigungen umfasst. Wenn die Konfiguration einer Unternehmens-App eine Zuweisung erfordert, können nur Benutzer*innen die App verwenden, die dieser App direkt zugewiesen sind oder die Mitglied in einer Gruppe sind, die der App zugewiesen ist.

Wenn Ihre App über definierte App-Rollen verfügt, die Benutzer*innen und Gruppen als Mitglieder zulassen, und der App ein Benutzer/eine Benutzerin oder eine Gruppe zugewiesen wird, muss eine der definierten App-Rollen Teil der Zuweisung des Benutzers/der Benutzerin oder der Gruppe zur App sein. Wenn Ihre App nur erhöhte Rollen (wie z. B. admin) für die App definiert hat, werden allen Benutzern und Gruppen die Administratorrolle zugewiesen. Wenn Sie eine Basisrolle (wie z. B. user) definieren, können Benutzern und Gruppen, die der App zugewiesen sind, die Basisbenutzerrolle zugewiesen werden.

Durch die Verwendung von Rollen lassen sich nicht nur Überschreitungsansprüche für Gruppen vermeiden. Ein weiterer Vorteil besteht darin, dass keine Zuordnung zwischen einer Gruppen-ID oder einem Gruppennamen und ihrem/seinem Zweck in der App erforderlich ist. Beispielsweise kann Ihr Code nach dem Administratorrollenanspruch suchen, anstatt Gruppen in den groups Ansprüchen zu durchlaufen und zu entscheiden, welche Gruppen-IDs die Administratorfunktionalität zulassen sollen.

Überprüfen und Verwenden von Rollen in Ihrem Code

Wenn Sie App-Rollen für Ihre App definieren, liegt es in Ihrer Verantwortung, Autorisierungslogik für diese Rollen zu implementieren. Informationen zum Implementieren der rollenbasierten Zugriffssteuerung in Anwendungen finden Sie unter „Implementieren von Autorisierungslogik“ in Ihren Apps.

Nächste Schritte