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.

User oder Service?

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", 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 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. 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. OnPremises 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.

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.

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