Grundlegendes zum reinen Anwendungszugriff
Wenn eine Anwendung direkt auf eine Ressource wie Microsoft Graph zugreift, ist ihr Zugriff nicht auf die Dateien oder Vorgänge beschränkt, die einem einzelnen Benutzer zur Verfügung stehen. Die App ruft APIs direkt mit ihrer eigenen Identität auf, und ein Benutzer oder eine App mit Administratorrechten muss sie für den Zugriff auf die Ressourcen autorisieren. Bei diesem Szenario handelt es sich um den reinen Anwendungszugriff.
Wann sollte ich den reinen Anwendungszugriff verwenden?
In den meisten Fällen ist der reine Anwendungszugriff breiter und leistungsfähiger als der delegierte Zugriff. Daher sollten Sie den reinen App-Zugriff nur verwenden, wenn dies erforderlich ist. Er ist normalerweise die richtige Wahl, wenn:
- Die Anwendung muss automatisch ohne Benutzereingabe ausgeführt werden. Beispielsweise ein tägliches Skript, das E-Mails von bestimmten Kontakten überprüft und automatisierte Antworten sendet.
- Die Anwendung muss auf Ressourcen zugreifen, die mehreren verschiedenen Benutzern gehören. Beispielsweise muss eine Sicherungs-App oder eine App zur Verhinderung von Datenverlust Nachrichten von vielen verschiedenen Chat-Kanälen mit jeweils unterschiedlichen Teilnehmern abrufen.
- Sie sind versucht, Anmeldeinformationen lokal zu speichern und der App zu erlauben, sich „als“ Benutzer oder Administrator anzumelden.
Im Gegensatz dazu sollten Sie den reinen Anwendungszugriff niemals dort verwenden, wo sich ein Benutzer normalerweise anmeldet, um seine eigenen Ressourcen zu verwalten. Bei diesen Arten von Szenarien muss der delegierte Zugriff verwendet werden, um über die Mindestberechtigungen zu verfügen.
Autorisieren einer App zum Tätigen von reinen Anwendungsaufrufen
Um reine App-Aufrufe tätigen zu können, müssen Sie Ihrer Client-App die entsprechenden App-Rollen zuweisen. App-Rollen werden auch als reine Anwendungsberechtigungen bezeichnet. Es handelt sich um App-Rollen, da sie Zugriff nur im Kontext der Ressourcen-App gewähren, die die Rolle definiert.
Wenn Sie beispielsweise eine Liste aller Teams lesen möchten, die in einer Organisation erstellt wurden, müssen Sie Ihrer Anwendung die Microsoft Graph-App-Rolle Team.ReadBasic.All zuweisen. Diese App-Rolle ermöglicht das Lesen dieser Daten, wenn Microsoft Graph die Ressourcen-App ist. Diese Zuweisung weist Ihre Client-Anwendung nicht einer Teams-Rolle zu, die es ihr möglicherweise ermöglicht, diese Daten über andere Dienste anzuzeigen.
Als Entwickler müssen Sie alle erforderlichen reinen App-Berechtigungen konfigurieren, die in Ihrer Anwendungsregistrierung auch als App-Rollen bezeichnet werden. Sie können die von Ihrer App angeforderten reinen App-Berechtigungen über das Azure-Portal oder Microsoft Graph konfigurieren. Der reine App-Zugriff unterstützt keine dynamische Zustimmung, sodass Sie zur Laufzeit keine einzelnen Berechtigungen oder Berechtigungssätze anfordern können.
Nachdem Sie alle Berechtigungen konfiguriert haben, die Ihre App benötigt, muss sie die Administratoreinwilligung für den Zugriff auf die Ressourcen erhalten. Beispielsweise können nur Benutzer und Benutzerinnen mit der Rolle „Administrator für privilegierte Rollen“ reine App-Berechtigungen (App-Rollen) für die Microsoft Graph-API erteilen. Benutzer und Benutzerinnen mit anderen Administratorrollen, z. B. Anwendungsadministrator und Cloudanwendungsadministrator, können reine App-Berechtigungen für andere Ressourcen erteilen.
Administratorbenutzer können reine App-Berechtigungen mithilfe des Azure-Portals oder durch programmgesteuertes Erstellen von Zuweisungen über die Microsoft Graph-API erteilen. Sie können auch innerhalb Ihrer App zur interaktiven Zustimmung auffordern, aber diese Option ist nicht zu empfehlen, da für den reinen App-Zugriff kein Benutzer erforderlich ist.
Consumer-Benutzer mit Microsoft-Konten, z. B. „Outlook.com“- oder Xbox Live-Konten, können niemals den reinen Anwendungszugriff autorisieren.
Befolgen Sie stets das Prinzip der geringsten Rechte: Fordern Sie auf keinen Fall App-Rollen an, die Ihre App nicht benötigt. Dieses Prinzip trägt zur Eindämmung von Sicherheitsrisiken bei, sollte Ihre App kompromittiert werden, und erleichtert es Administratoren, Ihrer App Zugriff zu gewähren. Wenn Ihre App beispielsweise nur Benutzer identifizieren muss, ohne ihre detaillierten Profilinformationen zu lesen, sollten Sie anstelle von User.Read.All die eingeschränktere Microsoft Graph-App-Rolle User.ReadBasic.All anfordern.
Entwerfen und Veröffentlichen von App-Rollen für einen Ressourcendienst
Wenn Sie einen Dienst in Microsoft Entra ID erstellen, der APIs für andere Clients zum Aufrufen verfügbar macht, sollten Sie möglicherweise den automatisierten Zugriff mit App-Rollen (reine App-Berechtigungen) unterstützen. Sie können die App-Rollen für Ihre Anwendung im Abschnitt App-Rollen Ihrer App-Registrierung im Microsoft Entra Admin Center definieren. Weitere Informationen zum Erstellen von App-Rollen finden Sie unter Deklarieren von Rollen für eine Anwendung.
Wenn Sie App-Rollen für andere Personen verfügbar machen, geben Sie dem Administrator, der sie zuweisen wird, eine klare Beschreibung des Szenarios an. App-Rollen sollten im Allgemeinen so eng wie möglich sein und bestimmte Funktionsszenarien unterstützen, da der reine App-Zugriff nicht durch Benutzerrechte eingeschränkt wird. Vermeiden Sie es, eine einzelne Rolle verfügbar zu machen, die vollständigen read- oder vollständigen read/write-Zugriff auf alle APIs und Ressourcen gewährt, die Ihr Dienst enthält.
Hinweis
App-Rollen (reine App-Berechtigungen) können auch so konfiguriert werden, dass die Zuweisung an Benutzer und Gruppen unterstützt wird. Stellen Sie sicher, dass Sie Ihre App-Rollen für Ihr beabsichtigtes Zugriffsszenario ordnungsgemäß konfigurieren. Wenn Sie beabsichtigen, dass die App-Rollen Ihrer API für den reinen App-Zugriff verwendet werden sollen, wählen Sie beim Erstellen der App-Rollen Anwendungen als einzige zulässige Mitgliedstypen aus.
Wie funktioniert der reine App-Zugriff?
Am wichtigsten am reinen App-Zugriff ist, dass die aufrufende App im eigenen Namen und als eigene Identität fungiert. Es gibt keine Benutzerinteraktion. Wenn die App einer bestimmten App-Rolle für eine Ressource zugewiesen wurde, hat die App uneingeschränkten Zugriff auf alle Ressourcen und Vorgänge, die von dieser App-Rolle gesteuert werden.
Sobald eine App App-Rollen (reine App-Berechtigungen) zugewiesen wurde, kann sie mithilfe des Client-Anmeldeinformationsflows oder eines anderen unterstützten Authentifizierungsflows ein Token für reine Apps von Microsoft Entra ID anfordern. Die zugewiesenen Rollen werden dem roles-Anspruch des Zugriffs-Tokens der App hinzugefügt.
In einigen Szenarien kann die Anwendungsidentität bestimmen, ob der Zugriff gewährt wird, ähnlich wie bei Benutzerrechten bei einem delegierten Aufruf. Beispielsweise gewährt die App-Rolle Application.ReadWrite.OwnedBy einer App die Möglichkeit, Dienstprinzipale zu verwalten, die die App selbst besitzt.
Beispiel für den reinen Anwendungszugriff – Automatisierte E-Mail-Benachrichtigung über Microsoft Graph
Das folgende Beispiel veranschaulicht ein realistisches Automatisierungsszenario.
Alice möchte ein Team jedes Mal per E-Mail benachrichtigen, wenn der Berichtsordner der Abteilung, der sich in einer Windows-Dateifreigabe befindet, ein neues Dokument registriert. Alice erstellt eine geplante Aufgabe, die ein PowerShell-Skript ausführt, um den Ordner zu untersuchen und nach neuen Dateien zu suchen. Das Skript sendet dann eine E-Mail mithilfe eines Postfachs, das durch eine Ressourcen-API (Microsoft Graph) geschützt ist.
Das Skript wird ohne Benutzerinteraktion ausgeführt, daher überprüft das Autorisierungssystem nur die Anwendungsautorisierung. Exchange Online überprüft, ob dem Client, der den Aufruf tätigt, vom Administrator die Anwendungsberechtigung (App-Rolle) Mail.Send erteilt wurde. Wenn der App die Berechtigung Mail.Send nicht erteilt wird, gibt Exchange Online eine Fehler aus.
| POST /users/{id}/{userPrincipalName}/sendMail | Client-App hat die Berechtigung „Mail.Send“ erteilt | Client-App hat die Berechtigung „Mail.Send“ nicht erteilt |
|---|---|---|
| Das Skript verwendet Alices Postfach zum Senden von E-Mails. | 200: Zugriff gewährt. Der Administrator hat der App erlaubt, E-Mails als beliebiger Benutzer zu senden. | 403: Nicht autorisiert. Der Administrator hat diesem Client nicht erlaubt, E-Mails zu senden. |
| Das Skript erstellt ein dediziertes Postfach zum Senden von E-Mails. | 200: Zugriff gewährt. Der Administrator hat der App erlaubt, E-Mails als beliebiger Benutzer zu senden. | 403: Nicht autorisiert. Der Administrator hat diesem Client nicht erlaubt, E-Mails zu senden. |
Das angegebene Beispiel ist eine einfache Abbildung der Anwendungsautorisierung. Der Exchange Online-Produktionsdienst unterstützt viele andere Zugriffsszenarien, z. B. das Einschränken von Anwendungsberechtigungen auf bestimmte Exchange Online-Postfächer.