Informationen zu Berechtigungen und zur Einwilligung

  • 3 Minuten

In Microsoft Identity Platform integrierte Anwendungen folgen einem Autorisierungsmodell, mit dem Benutzer und Administratoren den Zugriff auf Daten steuern können.

Die Microsoft Identity Platform implementiert das OAuth 2.0-Autorisierungsprotokoll. OAuth 2.0 ist eine Methode, über die eine Drittanbieter-App im Auftrag eines Benutzers auf im Web gehostete Ressourcen zugreifen kann. Alle im Web gehosteten Ressourcen, die in Microsoft Identity Platform integriert werden, verfügen über einen Ressourcenbezeichner bzw. Anwendungs-ID-URI.

Im Anschluss folgen einige Beispiele für im Web gehostete Microsoft-Ressourcen:

  • Microsoft Graph: https://graph.microsoft.com
  • API für Microsoft 365-E-Mail: https://outlook.office.com
  • Azure Key Vault: https://vault.azure.net

Dasselbe gilt für alle Ressourcen von Drittanbietern, die in die Microsoft Identity Platform integriert wurden. Diese Ressourcen können auch einen Satz von Berechtigungen definieren, die zum Unterteilen der Funktionalität der Ressource in kleinere Einheiten verwendet werden können. Die Unterteilung der Funktionen einer Ressource in kleinere Berechtigungssätze ermöglicht die Erstellung von Drittanbieter-Apps, von denen nur die spezifischen Berechtigungen angefordert werden, die diese Apps für ihr jeweilige Funktion benötigen. Benutzer und Administratoren können erkennen, auf welche Daten die App zugreifen kann.

In OAuth 2.0 werden diese Arten von Berechtigungssätzen Bereiche genannt. Oftmals werden sie auch als Berechtigungen bezeichnet. In Microsoft Identity Platform wird eine Berechtigung als Zeichenfolgenwert dargestellt. Eine App fordert die erforderlichen Berechtigungen an, indem sie die Berechtigung im scope -Anforderungsparameter angibt. Microsoft Identity Platform unterstützt mehrere klar definierte OpenID Connect-Bereiche sowie ressourcenbasierte Berechtigungen (jede Berechtigung wird durch Anfügen des Berechtigungswerts an den Bezeichner oder Anwendungs-ID-URI der Ressource angegeben). Beispielsweise wird die https://graph.microsoft.com/Calendars.Read-Berechtigungszeichenfolge verwendet, um die Berechtigung zum Lesen von Benutzerkalendern in der Microsoft Graph anzufordern.

Eine App fordert diese Berechtigungen meist durch Angabe der Bereiche in Anforderungen an den Microsoft Identity Platform-Autorisierungsendpunkt an. Bestimmte erhöhte Berechtigungen können jedoch nur mit der Einwilligung des Administrators gewährt werden. Sie können unter Verwendung des Endpunkts für die Administratoreinwilligung angefordert/gewährt werden.

Hinweis

Wenn bei Anforderungen an die Autorisierungs-, Token- oder Zustimmungsendpunkte für die Microsoft Identity Platform der Ressourcenbezeichner im Bereichsparameter weggelassen wird, wird angenommen, dass Microsoft Graph die Ressource ist. scope=User.Read entspricht beispielsweise https://graph.microsoft.com/User.Read.

Berechtigungstypen

Microsoft Identity Platform unterstützt zwei Arten von Berechtigungen: delegierte Berechtigungen und Zugriffsberechtigungen nur für Apps.

  • Delegierte Berechtigungen werden von Apps verwendet, bei denen ein Benutzer oder eine Benutzerin angemeldet ist. Bei diesen Apps willigt entweder der Benutzer oder ein Administrator in die von der App angeforderten Berechtigungen ein. An die App wird mit der Berechtigung delegiert, bei an die Zielressource gerichteten Aufrufen als angemeldeter Benutzer zu fungieren.

  • Zugriffsberechtigungen nur für Apps werden von Apps verwendet, die ohne vorhandenen angemeldeten Benutzer ausgeführt werden. Dies können beispielsweise Apps sein, die als Hintergrunddienste oder Daemons ausgeführt werden. Zugriffsberechtigungen nur für Apps erfordern die Einwilligung eines Administrators bzw. einer Administratorin.

Anwendungen in der Microsoft Identity Platform benötigen eine Zustimmung, um Zugriff auf benötigte Ressourcen oder APIs zu erhalten. Es gibt viele Arten von Einwilligungen, die Ihre App kennen muss, damit sie erfolgreich ausgeführt werden kann. Wenn Sie Berechtigungen definieren, müssen Sie auch wissen, wie Ihre Benutzer Zugriff auf Ihre App oder API erhalten.

Es gibt drei Einwilligungstypen: Die statische Benutzereinwilligung, die inkrementelle und dynamische Benutzereinwilligung und die Administratoreinwilligung.

Beim Szenario mit statischer Benutzerzustimmung müssen Sie im Azure-Portal in der Konfiguration der App alle erforderlichen Berechtigungen angeben. Wenn der Benutzer (oder ggf. der Administrator) keine Einwilligung für diese App erteilt hat, wird er von Microsoft Identity Platform aufgefordert, die Einwilligung zu diesem Zeitpunkt zu geben. Mit statischen Berechtigungen können Administrator*innen auch im Namen aller Benutzer*innen in der Organisation einwilligen.

Statische Berechtigungen der Anwendung werden im Azure-Portal definiert und sorgen dafür, dass der Code klar und einfach ist, aber für Entwickler kann dies ggf. zu Problemen führen:

  • Die Anwendung muss alle Berechtigungen anfordern, die nach der ersten Anmeldung des Benutzers jemals benötigt werden. Dies kann zu einer langen Liste von Berechtigungen führen, was Endbenutzer davon abhielt, bei der ersten Anmeldung den Zugriff der Anwendung zu genehmigen.

  • Die Anwendung muss frühzeitig alle Ressourcen kennen, auf die sie jemals zugreifen muss. Es ist schwierig, Apps zu erstellen, die auf eine beliebige Anzahl von Ressourcen zugreifen könnten.

Mit dem Microsoft Identity Platform-Endpunkt können Sie die in den App-Registrierungsinformationen im Azure-Portal definierten statischen Berechtigungen ignorieren und stattdessen Berechtigungen schrittweise anfordern. Sie können im Voraus gewisse Mindestberechtigungen anfordern und diese im Lauf der Zeit erweitern, wenn der Kunde zusätzliche App-Funktionen nutzt.

Hierzu können Sie die Bereiche angeben, die für Ihre Anwendung zu beliebigen Zeitpunkten benötigt werden, indem Sie die neuen Bereiche in den scope-Parameter einfügen, wenn Sie ein Zugriffstoken anfordern. Es ist nicht erforderlich, sie in den Informationen der Anwendungsregistrierung vorab zu definieren. Wenn der Benutzer noch keine Zustimmung zu den neuen Bereichen gegeben hat, die der Anforderung hinzugefügt wurden, wird er aufgefordert, nur den neuen Berechtigungen zuzustimmen. Die inkrementelle oder dynamische Einwilligung gilt nur für delegierte Berechtigungen und nicht für Zugriffsberechtigungen nur für Apps.

Wichtig

Die dynamische Zustimmung kann komfortabel sein. Sie stellt aber eine große Herausforderung in Bezug auf Berechtigungen dar, für die die Zustimmung durch einen Administrator erforderlich ist, da diese Berechtigungen in der Umgebung für die Administratorzustimmung zum Zustimmungszeitpunkt nicht bekannt sind. Falls Sie Administratorberechtigungen benötigen oder Ihre App eine dynamische Zustimmung verwendet, müssen Sie alle Berechtigungen im Azure-Portal registrieren (nicht nur die Berechtigungen, für die eine Administratoreinwilligung erforderlich ist). Dadurch können Mandantenadministratoren im Namen aller ihrer Benutzer zustimmen.

Zustimmung des Administrators Ist erforderlich, wenn Ihre App Zugriff auf bestimmte hochrangige Berechtigungen benötigt. Mit der Administratoreinwilligung wird sichergestellt, dass Administratoren über weitere Steuerungsmöglichkeiten verfügen, bevor sie Apps oder Benutzern hohe Berechtigungsstufen für den Zugriff auf Unternehmensdaten gewähren.

Die im Namen einer Organisation erteilte Administratorgenehmigung erfordert weiterhin die für die App registrierten statischen Berechtigungen. Legen Sie diese Berechtigungen für Apps im Portal für die App-Registrierung fest, wenn ein Administrator die Zustimmung im Namen der gesamten Organisation erteilen muss. Hierdurch werden die Zyklen reduziert, die der Administrator der Organisation zum Einrichten der Anwendung benötigt.

In einer Autorisierungsanforderung von OpenID Connect oder OAuth 2.0 kann eine App die erforderlichen Berechtigungen mithilfe des Abfrageparameters „scope“ anfordern. Wenn sich ein Benutzer beispielsweise bei einer App anmeldet, sendet die App eine Anforderung wie die folgende. Zur besseren Lesbarkeit wurden Zeilenumbrüche hinzugefügt.

GET https://login.microsoftonline.com/common/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&response_mode=query
&scope=
https%3A%2F%2Fgraph.microsoft.com%2Fcalendars.read%20
https%3A%2F%2Fgraph.microsoft.com%2Fmail.send
&state=12345

Der scope-Parameter ist eine durch Leerzeichen getrennte Liste von delegierten Berechtigungen, die von der App angefordert werden. Die einzelnen Berechtigungen werden jeweils durch Anfügen des Berechtigungswerts an den Ressourcenbezeichner (Anwendungs-ID-URI) angegeben. Die Anforderung im Beispiel gibt an, dass die Anwendung eine Berechtigung zum Lesen des Kalenders des Benutzers und Senden von E-Mails als Benutzer benötigt.

Nachdem der Benutzer seine Anmeldeinformationen eingegeben hat, überprüft Microsoft Identity Platform, ob es einen übereinstimmenden Eintrag für die Benutzerzustimmung gibt. Wenn der Benutzer in der Vergangenheit für keine der angeforderten Berechtigungen seine Zustimmung erteilt und der Administrator im Namen der gesamten Organisation diesen Berechtigungen nicht zugestimmt hat, wird der Benutzer durch Microsoft Identity Platform aufgefordert, die angeforderten Berechtigungen zu gewähren.