Azure AD Authentifizierung und Provisioning

Wer Office 365 nutzt, nutzt indirekt auch immer das AzureAD, indem alle Benutzer und Gruppen vorhanden sind. Diese können manuell oder mit AADConnect auf Bass eines lokalen Active Directory verwaltet werden. Zudem übernimmt das AzureAD auch die Authentifizierung für Exchange Online, SharePoint Online, und alle anderen Office 365 und Azure-Dienste. Je nach Einstellung erfolgt die Authentifizierung anhand im AzureAD hinterlegter Kennworte oder z.B. über einen ADFS-Service gegen den Anmelde-Forest des Benutzers. Alle Office 365 Dienste nutzen als die Identitätsdienste und Anmeldedienste des AzureAD. Da liegt der Wunsch doch nahe, auch andere Anwendungen diese Dienste nutzen zu lassen.

Der Große Vorteil dabei ist, dass man nicht für jede Drittanwendung einen "Relying Party Trust" auf seinem lokalen ADFS-Server einrichten muss und auch der Anbieter nicht für jeden Kunden eine Partnerschaft zur einem ADFS-Server des Kunden unterhalten muss. Ihm reicht eine einmalige Verbindung zum AzureAD und der Kunde muss der Applikation nur das Recht einräumen.

Hinweis:
Die früher mögliche Authentifizierung über "Azure Access Control service" wird zum Nov 2018 eingestellt. Siehe auch "Migrate from the Azure Access Control service" (https://docs.microsoft.com/en-us/azure/active-directory/develop/active-directory-acs-migration)

"Applikationen" in AzureAD

Und genau das ist mit Anwendungen in AzureAD auch möglich. Dazu müssen Sie natürlich als Office 365 Administrator nicht über die Verwaltungsseite von Office 365 ( https://portal.office365.com) arbeiten, sondern sich an der AzureAD-Verwaltung unter https://portal.azure.com/ anmelden.

Aber so einfach lässt AzureAD natürlich nicht "jeden" zu. Sie müssen die Applikation in ihrem AzureAD erst eintragen. Hier sehen Sie einen Auszug der im AzureAD von Net at Work hinterlegten Applikationen. Sie sehen sehr gut, dass verschiedene Microsoft-.Dienst wie z.B. Exchange Online hier schon vorhanden sind.

Dieser Eintrag ist pro Applikation erforderlich und beim Hinzufügen bietet ihnen AzureAD vier Auswahlmöglichkeiten an.

  • Eigene Applikation in Azure
    Sie betreiben eine Applikation also in Azure und nutzen natürlich das AzureID als Identity-Quelle und Authentifizierungsprovider
  • Lokale Anwendung
    Die Anwendung läuft nicht in der Cloud sondern in ihrem eigenen Datacenter oder einem anderen Service aber greift dann "remote" auf AzureAD zu.
  • Manueller Eintrag
    Hier können Sie dann den Namen und die URLs alle individuell eingeben.
  • Kataloganwendung
    Und wie sie hier schon sehen können, gibt es am 27. Apr 2017 alleine 2819 von Herstellern in Azure bereitgestellte Applikationskonfigurationen, die Sie direkt auswählen können. Rechts unten sehen Sie eine "Auswahl" und neben den Microsoft Apps gibt es hier z.B. auch Dropbox, Jive aber auch SalesForce und andere Dienste.

Passende Lizenz

Je nach Applikation sind dann noch noch die ein oder anderen Konfigurationseinstellungen erforderlich. Wenn Sie eigene "Nicht Katalog-Anwendungen" einbinden wollen, dann ist Azure AD Premium erforderlich.

Die Anlage einer "lokalen Anwendung" erfordert zumindest eine AAD Basic oder auch eine Premium-Lizenz

Nicht jede Funktion ist daher schon im Office 365 Standard-Paket enthalten.

Berechtigungen für Apps

Wenn Sie eine Applikation in AzureAD eintragen haben, dann kann Sie damit nicht nur die Authentifizierung des Benutzers durchführen, sondern sie kann auch als App alleine oder per "Impersonation" als der authentifizierte Benutzer auf Dienste zugreifen. Das geht natürlich nicht unkontrolliert. Als Administrator müssen Sie jede Schnittstelle von Office 365 explizit bei der App eintragen. Hier eine Liste der Schnittstellen

Nach der Auswahl der Schnittstelle sind dann noch die Berechtigungen zu setzen. Hier am Beispiel von Microsoft.Azure.ActiveDirectory

Es wird nach "Anwendungsberechtigungen" und nach "Delegierte Berechtigungen" unterschieden. Es gibt einmal die "Anwendungsberechtigungen", die die Anwendung als solches hat und die "Delegierte Berechtigungen", die die Anwendung nur für den Benutzer ausüben kann, der sich hier angemeldet hat.

Lassen Sie sich nicht von dem grünen "Ja" am Ende irritieren. Damit ist gemeint, dass ein Administrator dieses Recht noch bestätigen muss. Sie können das AzureAD nämlich so konfigurieren, dass jeder Benutzer eigene Applikationen im Tenant anlegen kann. Die umfangreicheren Berechtigungen kann der Benutzer zwar anwählen aber stehen unter Vorbehalt der Zustimmung durch einen TenantAdmin.

Beachten Sie, dass es einige sehr umfangreiche APIs wie z.B. Graph gibt. Eine Applikation kann über die entsprechenden APIs dann auch auf E-Mails, Tasks, Notizen u.a. des Benutzers zugreifen. Das kann ja gewollt sein, z.B. wenn eine Cloud-CRM die Aufgaben, Termine und Kontakte des Benutzers in Exchange Online aktualisieren will.

Rechte für Microsoft Graph

Gerade "Microsoft Graph" ist hier eine universelle leistungsfähige aber damit auch gefährliche Schnittstelle. Über eine einheitliche Schnittstelle als Proxy kann eine Applikation quasi auf alle Daten zugreifen, Wenn der Administrator die falschen Rechte delegiert. Die ein Auszug der Rechte, die schon schnell deutlich  machen, wie umfangreich dies werden kann. Die Anwendungsberechtigungen sind ja noch überschaubar.

Zu den „Basic Profiles“ gehören beim User die folgenden Informationen: Displayname, Lastname, Firstname, Photo, Email. Bei Gruppen ist es sogar nur der Displayname

Aber die delegierten Berechtigungen können schon sehr weit gehen.

Über die Berechtigungen der Applikation selbst auf z.B. das AzureAD kann die Anwendung auch Stammdaten aus ihrem AD auslesen. Wozu das nützlich ist, lesen sie im folgenden Kapitel:

Userdaten und Provisioning ?

ADFS ist aber keine „Identity-Plattform“ sondern erst mal „nur“ ein System, welches für den Benutzer ein Token ausstellt, welches einige Informationen des Benutzers enthält. In der Applikation muss der Benutzer natürlich immer noch gepflegt werden und dort werden auch weitere Einstellungen des Benutzers hinterlegt. Bei einer direkten Anmeldung per ADFs bekommt die Applikation natürlich die vom Admin konfigurierten ADFS-Token-Felder, die mit lokalen Daten gefüllt sein können. Aber ADFS selbst ist erst mal kein Zugang zu einem Verzeichnis. Es gibt über ADFS keine Schnittstelle um eine Liste der möglichen Benutzer zu erhalten. Daher muss die jeweilige Applikation sich natürlich einen anderen Weg suchen, um die Benutzer in ihrem eigenen Datenbestand anzulegen und zu pflegen.

  • Manuell
    d.h. ein Admin legt den User auf dem AppService an, damit sich der User dann mit ADFS anmelden kann. Das ist bei wenig Fluktuation und wenigen Usern praktisch und einfach
  • DirSync aus dem lokalen Active Directory oder anderen Quellen (CSV Date o.ä.)
    Natürlich konnte die Useranlage auch vom lokalen System aus zur Applikation erfolgen. Das macht AADConnect z.B. für die Verwaltung der Office 365 User. Diverse AntiSpam-Systeme machen dies auch so, dass ein lokaler Service die Stammdaten gefiltert zur App überträgt.
  • DirSync aus dem AzureAD (AzureAD Api oder Graph)
    Nun ist es ja so, dass viele Firmen heute schon ihre Benutzer „auch“ in der Office 365 Cloud und damit dem AzureAD haben. Sie können im Azure AD entsprechende „Applikationen“ pflegen, über die dann die Applikation sich gegen das AzureAD authentifiziert und die Daten lesen darf. Das geht normalweise über Die AzureAD-API oder Graph. Bei der Einrichtung der Applikation in ihrem AzureAD für die Authentifizierung können Sie auch diese Schnittstellen einrichten
  • AdHoc Anlage über ADFSToken
    Eine letzte Option ist quasi ein automatisches Anlegen bei der ersten Anmeldung. Wenn ein User auf den Dienst zugreift, kann er dort seien UPN eingeben und der Dienst prüft dann einfach, ob eine Anmeldung damit möglich ist. Wenn dies der Fall ist, dann „kennt“ der Dienst den Benutzer und  alle Felder, die sie per ADFS im Token mit gegeben haben. Diese kann die Applikation nutzen um „on the fly“ ein Konto anzulegen. Wenn man dann z:B. die Rolle des Benutzers auf dem System als ADFS-Feld mitgibt, könnte man damit auch die Funktionalität der Anwendung steuern.

Die manuelle Pflege und eine AdHoc Anlage hat natürlich die Einschränkung, dass in der Quelle wieder ausgeschiedene Benutzer auf der Applikationsplattform nicht automatisch gelöscht werden. Das ist natürlich teuer, wenn die Applikation "pro Benutzer" lizenziert wird. Denkbar ist natürlich, dass die Applikation regelmäßig prüft, welche Benutzer sich schon länger nicht mehr angemeldet haben und diese dann Deaktiviert oder eine Rückfrage startet. Aber auch wenn so ermittelt wird, dass ein Benutzer nicht mehr genutzt wird, ist es pro Applikation zu überlegen, wie damit dann umgegangen wird. Oft sind ja Daten (z.B. Wiki-Seiten als Autor) mit dem Benutzer verknüpft. Das "Exit-Management" ist eine ganz eigene Aufgabenstellung.

Besser lässt sich die Erkennung obsoleter Benutzer natürlich über einen Verzeichnisabgleich lösen. AzureAD bietet ja die entsprechenden Möglichkeiten auch an. Sie müssen nur entsprechend berechtigt werden.

Beispiel EDX.ORG

Die Plattform für Schulungen und Vorträge kann z.B. direkt mit dem AzureAD verbunden werden. Auf edx.org können Universitäten aber auch Firmen wie z.B. Microsoft Curse anbieten. Die Teilnehmer müssen sich natürlich authentifizieren, damit die Plattform die bereits gebuchten oder angefangenen Kurse wieder anzeigen kann. So bietet Microsoft selbst z.B. Online Kurse für Exchange, Skype for Business etc. an.

Natürlich können sich Teilnehmer direkt und losgelöst von Firmenkonten und Office 365 anmelden. Aber es ist eben auch möglich sich über "Microsoft" anzumelden

Wenn der Anwender diese Option wählt, dann leitet edx.org den Browser auf "login.microsoft.com" um. Die URL sieht etwas so aus (Zur Lesbarkeit umgebrochen

https://login.microsoftonline.com/common/oauth2/authorize?
scope=openid+profile+User_impersonation
&state=hV5sfHnihXNOfegugwYP0EZ6M2zhDC48
&redirect_uri=https://courses.edx.org/auth/complete/azuread-oauth2/
&response_type=code
&client_id=5ea2d1b0-xxxx-xxxx-xxxx-xxxxxxxxxxxx

Die Client_ID passt zur "Anwendungs-ID" in der AzureAD Applikation

Über die Protokollierung dank Fiddler ist dann zu sehen, dass danach wieder der Rücksprung an die in der Applikation konfigurierte "URL für die Startseite" erfolgt.

Da ich in dem Browser schon in Office 365 angemeldet war, ist hier keine Anmeldung per ADFS zu sehen. Der Browser hat einfach die Office 365 Cookies einfach mit gesendet. edx.org holt sich dann aus dem Rückgabewert die Informationen zum Benutzer. Diese Daten sind aber zumindest auf die Schnelle nicht "lesbar".

Einen etwas faden Beigeschmack haben natürlich all die nachfolgenden Requests, die alle die edx-org-Seite als "Referrer" haben. Wer Cloud-Dienste nutzt, speziell kostenfreie Dienste, bezahlt dann auch mit seinen Daten oder füllt zumindest die "Traces" verschiedener Firmen, die damit immer mehr über sie wissen.

Anzeige der Logins

AzureAD protokolliert natürlich auch Anmeldungen und sie können im AzureAD-Portal dann auch gut sehen, wie und von Wem der Anmeldeservice genutzt wird:

Für die Fehlersuche und Analyse sind solche Informationen natürlich wichtig. Allerdings wird hier nicht protokolliert, wie Sie dann mit der Applikation selbst arbeiten.

Weitere Applikationen

EDX.ORG ist nicht die einzige Applikation. Sie müssen nur mal gezielt nach Cloudapplikationen und AzureAD oder ADFS suchen oder in ihrem Office AzureAD eine Applikation aus dem Marketplace anlegen wollen. In der Liste tauchen durchaus auch Namen auf wie

  • Wikipedia, Wordpress
  • MailChimp, Yahoo
  • Salesforce,SugarCRM,SageCRM, SAP
  • GitHub.com, Khan Academy, edx.org
  • Amazon AWS
  • Teamviewer, Cisco Partner Login, My Ctrix, MyIBM,
  • Und viele andere über Drittanbieter

Quasi jeder Hersteller, der mittlerweile etwas auf sich hält, hat in seine Software eine Rücksprungadresse und eine Vertrauensstellung zu AzureAD eingerichtet, so das Kunden zur Authentifizierung einfach das AzureAD nutzen können.

Weitere Links