Im Grunde dreht sich alles um Tokens, die über den Zugriff auf eine Anwendung im Web entscheiden. Da Office 365 aus der Cloud stammt und über HTTPS zugänglich ist, müssen diese Tokens, anders als ihre On-Premises-Brüder wie etwa in Kerberos (Tickets), webtauglich sein. Die Zugriffsmuster für Anwendungen in der Cloud, nicht nur Office 365, sind aber sehr ähnlich zu dem, was mit dem Windows Active Directory (AD) schon seit Jahren passiert.
Die Nutzung von Office 365 gelingt nur nach erfolgreicher Authentifizierung, wonach das AD – in der Cloud Azure AD (AAD) – einen Zugriffstoken für die Anwendung ausstellt. Der Zugriffstoken wird von der entsprechenden Anwendung ausgewertet und dank Integration in das AD oder das AAD für vertrauenswürdig befunden. Im AD entscheidet die Anwendung dann anhand konfigurierter Berechtigungen, welche Rechte ein authentifizierter Benutzer erhält.
Ähnlich funktioniert das auch für das AAD, allerdings hat sich Microsoft für die Nutzung der Dienste über das Internet einige Besonderheiten einfallen lassen. Schließlich gelten für das AAD und SaaS-Anwendungen aus der Wolke andere Gesetze als für traditionelle Windows-Anwendungen innerhalb des Netzwerkes, denn die Cloud ist von überall erreichbar und Unternehmen sowie Nutzer wünschen sich zunehmend mehr Unterstützung für flexible Arbeitsmethoden.
Obwohl wir diesen Artikel auf einem Office-365-Beispiel aufbauen, sind alle Szenarien auch für andere SaaS-Anwendungen anwendbar, sofern diese im AAD integriert sind [1]. Die Zugriffseinstellungen für Office 365 sind ohne Conditional Access per Vorgabe sehr liberal: Jeder Anwender mit einer gültigen Lizenz und gültiger Authentifizierung kann den Dienst nutzen – unabhängig vom Gerät, Ort oder Clientanwendung.
Das AAD erteilt nicht nur Tokens anhand einer erfolgreichen
...Der komplette Artikel ist nur für Abonnenten des ADMIN Archiv-Abos verfügbar.