Graph Berechtigungen

Die Microsoft Graph-Schnittstelle ist nicht anonym erreichbar. Sie müssen sich daher "Anmelden". In der Regel gibt es zwei Varianten und mit Exchange kommt eine dritte Option dazu. Verstehen und lesen Sie dazu auch die Seite Authentifizierung im Wandel der Zeit.

Authentifizierung ist Pflicht

Microsoft Graph ist Microsofts universelle Schnittstelle auf Informationen in Exchange, Teams, SharePoint, OneDrive und viele andere Datentöpfe und sogar Einstellungen. Allerdings ist ein Zugriffe weder anonym noch einfach mit "Benutzername/Kennwort" möglich, denn Graph nutzt immer die "moderne Authentifizierung". Damit haben wir Voraussetzungen zu erfüllen:

  • App muss bekannt sein
    Eine einfache Anmeldung mit "Benutzername/Kennwort" ist nicht möglich. Sie müssen entweder eine App selbst definieren oder der vom Hersteller bereitgestellten App-Registration vertrauen
  • Delegate oder App
    Dann gibt es die Unterscheidung, um die Software die Anmeldedaten vom Benutzer bekommt oder eigenständig arbeiten darf. Nicht jede API erlaubt aber die Aktion als eigenständige "Application".
  • Berechtigungen und Consent
    Die gewünschten Berechtigungen müssen nicht nur bei der App definiert werden sondern vom Administrator für den Tenant  oder durch den Benutzer abgesegnet werden.
  • Optional: Zielberechtigungen
    Wenn Sie Inhalte in Exchange lesen wollen, kennt Graph nur "Mail.Read" und "Mail.Read.All". Innerhalb von Exchange kann aber hier weiter unterschieden werden. Bislang kenne ich keine anderen Datentöpfe, die diese Funktion bieten.

All diese Einstellungen müssen Sie vornehmen, ehe die erste Applikation sich ein Ticket besorgen kann.

Achtung:
Sie könne auf dem Tenant steuern, ob Benutzer auch selbst ihre Zustimmung für Apps und Berechtigungen geben dürfen. Wenn Sie dies erlauben, können Benutzer ohne ihre Mithilfe für sich selbst Apps addieren.

User oder Application?

so dass auch die verwendete Applikation bzw. das Skript erst "bekannt" gemacht werden muss. Die App muss im AzureAD registriert werden. Hier können Sie als Administrator die Berechtigungen festlegen. Bei Graph gibt es zwei unterschiedliche Arten:

Wie üblich gibt es wieder mehrere Kombinationen:

Zugriff Beschreibung

Delegate Permission

Damit ist der normale Zugriff gemeint, wenn ein Anwender eine App startet, um auf Informationen zuzugreifen, die er regulär auch bekommen kann.

Lassen Sie sich also nicht von dem Wort "Delegate" verwirren, denn es geht dabei nicht um Stellvertreter und auch nicht im "Impersonation" o.ä..

 Der Anwender gewährt der Applikation das Recht, sich mit den Daten des Benutzers, sich bei Graph anzumelden. Wenn der Administrator für die App noch keine Zustimmung (Consent) eingerichtet hat, dann wird der Anwender um Zustimmung durch Graph gebeten. Der Anwender "sieht" also, welche Applikation gerade Zugriff anfordert und die Anmeldedaten des Anwender nutzt.

Es gibt hier dann noch die Unterscheidung, wie lange die Applikation das erhaltene Token nutzt. Ein Programm, welches der Anwender selbst startet, kann das Token zwischenspeichern aber wenn es nicht läuft, kann muss die Applikation nach dem Ablaufen ein neues Token mit den Anmeldedaten des Benutzers anfordern.

Delegate Offline Permission

"Delegate" ist nett, wenn der Anwender die Software selbst startet und eine Anmeldung erfolgt. Solange die Software bei dem Benutzer auch läuft, kann Sie das Token auch selbst immer wieder verlängern und solange das Access-Token gültig ist, kann die App auch immer wieder ein neues Refresh-Token besorgen. Aber wenn die App beendet wird und die Tokens nicht gecached wurden oder abgelaufen sind dann muss eine Reauthentifizierung erfolgen.

Natürlich könnte eine App das Refresh und Access-Token an einen permanent laufenden "Service" übergeben, der immer wieder eine Verlängerung beantragt bis das Refresh-Token abgelaufen ist. Als Entwickler kann man sogar "unendlicih güötige Refresh-Tokens" ausstellen aber sollte sich dann Gedanken machen, wie diese zurückgezogen werden können. Aber sicher ist das nicht unbedingt und fördert nicht das Vertrauen. Es gibt aber eine besondere Berechtigungen, dass ein Programm auch ein "Offline Token" anfordern kann, welches explizit für die Nutzung ohne den Anwender vorgeshen ist:

Offline_access is defined in OpenID Connect as an OAuth Scope value to request offline access: Offline_access - OPTIONAL This scope value requests that an OAuth 2.0 Refresh Token be issued that can be used to obtain an Access Token that grants access to the End-User's userinfo_endpoint even when the End-User is not present (not logged in).
Quelle: https://ldapwiki.com/wiki/Offline_access

Dann gibt es ein Programm, welches "als Benutzer" z.B. auf einem Server läuft, kann das Token auch selbst wieder verlängern und damit auch weiter arbeiten, wenn der Anwender selbst nicht mehr aktiv ist.

Application Permission

Dann gibt es noch die Programme, die gar keine Mithilfe des Anwenders benötigen. On-Premises waren das dann die Dienste, die mit einem entsprechend privilegierten Konto z.B. per EWS und Impersonation auf Postfächer zugegriffen haben. Auch das ist mit Graph möglich. Allerdings nutzen wir dazu keine "Benutzer" mit Kennwort und App sondern die App selbst bekommt die Berechtigungen und authentifiziert sich mit entsprechenden "App Credentials". Das kann ein Kennwort oder auch ein Zertifikat sein, welche bei der Definition der App angelegt werden.

Hier möchte ich auch noch mal auf einen Webcast von Microsoft verweisen, in dem die Rechte und Zusammenhänge z.B. durch folgendes Bild beschrieben werden:


Quelle: "Understanding single sign-on (SSO) with Azure AD and Microsoft Teams" https://youtu.be/SaBbfVgqZHc?t=1164

Interessant ist der Absatz, dass eine App nicht nur pro Tenant definiert werden kann, sondern der Anbieter einer App diese in seinem Tenant als "Shared" Application einrichtet.

So kann ich eine App definieren und auch den Code dafür betreiben. Meine "Kunden" können diese App dann einfach in ihrem Tenant referenzieren, indem Sie meine App al "Enterprise Application" aus dem Store einbinden. Damit ergeben sich ganz interessante B2B-Szenarien, wenn ein Kunde einfach nur noch einen Service einkauft aber selbst keine Ressourcen mehr bereitstellen muss. Ich kann meinerseits den Code dann einfach aktualisieren oder erweitern ohne das der Kunde selbst aktiv werden muss.

What are App Application Permissions vs Delegated Permissions? | One Dev Question: Hirsch Singhal
https://www.youtube.com/watch?v=6R3W9T01gdE

Getting Started with Microsoft Graph and Consent Permissions
https://www.youtube.com/watch?v=yXYzgWWVdSM

Applications permissions and consent
https://www.youtube.com/watch?v=80RdKeeDTss

Scope

Ein wichtiger Unterschied ist der Scope von Berechtigungen. Wenn ein Anwender oder Administrator einer App die "Delegated"-Berechtigungen einrichtet, damit der Anwender die App nutzt, dann kann der Code auch nur auf die Daten des Anwender zugreifen. Anders sieht es aus, wenn ein Administrator eine "Application"-Permission einrichtet. Dann  hat die App erst einmal die Berechtigungen auf alle Benutzer in dem Tenant.

 

Das Berechtigungsmodell von Graph lässt hier erst einmal noch keine weitere Unterscheidung zu. Eine App mit "Application Permission" sollte also immer genau bewertet werden, ob Sie entsprechend vertrauenswürdig ist. Eine Beschränkung auf einen Benutzerkreis o..ä. muss die App selbst implementieren.

Sonderfall Exchange: Scoped EWS Impersonation

Das Exchange Postfach ist so etwas wie das Herzstück der Cloud und als Anwender habe ich in meinem Postfach nicht nur belanglose Newsletter sondern vor allem auch meine Termine und Kontakte und das Postfach ist auch das Ziel für z.B. Kennwort-Rücksetz-Mails. Hier wäre es leichtsinnig, wenn eine App die "Application Permission:Mail.Read" bekommen und damit alle Inhalt in allen Postfächern lesen könnte. Graph greift aber seinerseits auf Exchange APIs zu und Exchange bekommt die Information über die eigentliche Application und die Berechtigungen mit. Für Exchange hat Microsoft daher einen Weg geschaffen, mit der Sie Application-Berechtigungen auf eine Teilmenge der Postfächer beschränken können.

Diese feinere Steuerung von Berechtigungen scheint aber nur für Exchange möglich zu sein. Application Permissions für OneDrive, Teams, SharePoint und andere Datentöpfe beziehen sich auf alle Bneutzer.

Benutzerrechte verwalten

Als Administrator können Sie natürlich steuern, ob Benutzer selbst ihre Zustimmung für eine App geben möchten. Dies ist auch dringend angeraten hier aufzupassen, damit Anwender nicht irrtümlich einer nicht vertrauenswürdigen App etwaige Berechtigungen einräumen.

Auch sollten Anwender manchmal in ihrem Portal kontrollieren, welche App noch Berechtigungen benötigt. Dies gilt nicht nur für Office 365 sondern natürlich acuh für andere Identity Provider

Administratoren können daher z:B. die Zustimmung der Benutzer unterbinden, so dass der Benutzer den Administrator bitten muss. So können Sie als Firma auch wunderbar verhindern, dass Anwender andere Dienste in der Cloud einfach einbinden, ohne einen formalen Beantragungs- und Bestellprozess zu durchlaufen.

Weitere Links

Applications permissions and consent
https://www.youtube.com/watch?v=80RdKeeDTss