Azure AD Enterprise Applications

23. Januar 2019

Auf der vergangenen SPUG Rhein-Necker durfte ich einen Vortrag zum Thema Azure AD Enterprise Applications halten. Die Erkenntnisse aus der Vorbereitung für den Vortrag möchte ich auch hier kurz teilen.

Was sind Azure AD Enterprise Applications?

Unter dem sperrigen Begriff versteckt sich die Single Sign On Funktionalität, die das Azure AD auch für andere Applikationen zur Verfügung stellt. Konkret geht es darum, dass man aus einem Katalog von über 3000 SaaS-Anwendungen sich mehrere aussuchen und zu seinem Azure AD Tenant hinzufügen kann. Einmal konfiguriert, findet der Anwender dann über die Adresse https://myapps.microsoft.com die hinzugefügten Apps als eigene Kachel. Wurde alles richtig gemacht, führt ihn ein Klick auf die zugehörige Kachel direkt zur Applikation und authentifiziert ihn in der Zielanwendung. Wenn also die Sales-Abteilung durchgehend Zugriff auf die Salesforce-Cloud benötigt, braucht Sie sich dort kein eigenes Passwort mehr merken. Der normale Firmenaccount wird dann zur Authentifizierung genutzt. Darüber hinaus kann man auch automatisiert Konten im Zielsystem anlegen und löschen lassen. Um beim vorherigen Beispiel zu bleiben: Wird jemand im Azure AD in die Gruppe „Salesforce-Users“ aufgenommen, wird für ihn automatisch ein Account bei Salesforce angelegt. Verlässt er das Unternehmen wird der Account auch automatisch wieder entfernt.

Single Sign On

Der Single-Sign on kommt in verschiedenen Ausbaustufen. Die interessanteste davon ist die SAML-Konfiguration. Neben SAML gibt es auch noch die Option „Password based“, welche auf ein Browser-Plugin angewiesen ist. Dieses Browser-Plugin ist mehr oder weniger ein besserer Passwort-Manager und überzeugt nicht unbedingt.

Für den SAML-basierten SSO braucht man bei einigen der Dienste zunächst einen kostenpflichtigen Account (so z.B. bei github), bzw. spezielle Firmen-Konten (z.B. bei Pluralsight). Die eigentliche Konfiguration des Dienstes ist dann recht einfach vorzunehmen, denn für fast alle der über 3000 SaaS Applikationen, die bereits im Katalog aufgenommen wurden, gibt es einen speziell angepassten Hilfe-Artikel. Aber auch wenn man eine Custom-Application hat, sollte es problemlos möglich sein diese an das Azure AD anzubinden. Bei SAML handelt es sich ja immerhin um einen recht verbreiteten Standard.

Provisioning

Für das Provisioning von Usern in eine andere Applikation gibt es bei weitem nicht so viele Anwendungen, wie für das Thema SSO. Dabei setzt auch das Provisioning auf einen offenen Standard: SCIM. Auch beim Provisioning gilt, dass es zu jeder unterstützen App zumindest eine grundlegende Dokumentation gibt, die eine Nutzung erheblich erleichtert.

Bleibt die Frage, welche Nutzer jetzt provisioniert werden und SSO erhalten. Hier kann man auf Ebene der Applikation einfach Benutzer oder Gruppen hinzufügen, die für diese Applikation freigeschaltet werden sollen. Nach einer Freischaltung für einen User und einem erneuten Anmelden taucht die App dann unter der Adresse https://myapps.microsoft.com als neue Applikation auf.

Azure AD Premium-Features

Da Microsoft damit auch etwas verdienen will, gibt es natürlich sinnvolle Mehrwerte durch die Bezahl-Variante des Azure-AD. Die wichtigsten Punkte in Kürze:

Über eine Azure AD Gruppe mit dynamischer Mitgliedschaft kann man z.B. folgende Regel anlegen: Jeder der bei „Department“ den Wert „Sales“ hat, kommt in die Gruppe „Salesforce-User“. Diese Gruppe wiederum ist natürlich mit der Applikation verknüpft, sodass automatisch alle User aus dem Sales-Department einen Salesforce-Account erstellt bekommen.
Der SSO kann mit Hilfe von Conditional Access weiter abgesichert werden. Damit profitiert man von den zahlreichen Security-Features und kann z.B. auch für Dritt-Applikationen eine Multi-Faktor-Authentifizierung aktivieren.
Das Limit von 10 SSO-Applikationen fällt weg.

Die Praxis

In meinem Vortrag für die SPUG hatte ich mir github als Beispiel herausgepickt. Der Hintergedanke war, dass github sicherlich gut ist in der Unterstützung der offenen Protokolle und gleichzeitig auch für viele (Microsoft-)Mitarbeiter eine oft genutzte Applikation ist.

Leider ist gerade github im Bereich Provisioning nicht so weit, wie man sich wünschen würde. Konkret wird nämlich nur die Zugehörigkeit eines bereits bestehenden github-Users zu einer Organisation innerhalb von github „provisioniert“. Das bedeutet, dass man nur die Arbeit abgenommen bekommt, neue User zur Organisation in github einzuladen. Der Anwender muss aber nach wie vor ein Konto bei github registrieren. (Es besteht natürlich noch die Möglichkeit, dass ich einen Fehler in der Konfiguration gemacht habe. Falls es also jemand besser weiß, gerne melden!)

Man merkt also, dass hier noch Überraschungen auf einen warten. Allerdings bin ich durchaus optimistisch, dass sich die grundlegende Architektur weiter etablieren wird. Einmal ausgereift ist das ein riesiger Benefit des Azure Ads.