Automatisierung der ADFS Home Realm Discovery bei mehreren Azure AD Tenants/Domains und Identity Providern

Bei einem Kunden war der folgenden Anwendungsfall gegeben: Office 365 und Azure wird eingesetzt, dabei erfolgt das Identity Management allerdings mit unterschiedlichen Domains (Sowohl DNS als auch ADDS Domains), beziehungsweise Azure AD Tenants. Allerdings war die Anforderungen, dass die Authentifizierung wiederum mittels einer Zentralen ADFS Farm erfolgen soll an die wieder zwei Claims Provider verknüpft sind.

Föderation von Azure AD zu ADFS   

Grundsätzlich ist das Föderieren von zwei oder mehreren Azure AD Domains/Tenants kein Problem und relativ einfach zu lösen. Seit geraumer Zeit ist kann man beim Einrichten des ersten „Relying Party Trusts“ zwischen Azure AD und ADFS mittels PowerShell einrichten. Dabei gibt es verschiedene CmdLets die eine Föderierung einrichten und den Switch –SupportMultipleDomains unterstützen. Dabei wird auf ADFS der Trust für mehrere Domains einrichten. Der Switch sorgt unter anderem dafür, dass der FederationServiceIdentifier auf Azure AD, als auch der IssuerID Claim in ADFS, Domain-spezifisch konfiguriert eingerichtet wird.

In ADFS wird so eine neue Claim Rule hinzugefügt die anhand des Claims UPN, den Wert des IssuerID Claims dynamisch setzt:

c:[Type == “http://schemas.xmlsoap.org/claims/UPN“]
=> issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid“, Value = regexreplace(c.Value, “^((.*)([.|@]))?(?<domain>[^.]*[.].*)$”, “http://${domain}/adfs/services/trust/“));

In meinem Anwendungsfall hatte ich allerdings mit der Schwierigkeit zu kämpfen, das ich pro registrierter Domain ebenfalls einen anderen Identity Provider hatte und (das wäre noch relativ einfach) einer von beiden IdPs ist kein Active Directory sondern ein SAML 2.0 IdP.

Well I tried…

Da bei dem Kunden-Setup die Azure AD pro Tenant getrennt voneinander betrachtet werden, war meine erste Idee zwei Relying Party Trusts einzurichten. Dabei habe ich das Tenant spezifische MetaData-XML von den beiden Azure AD Tenants heruntergeladen und die beiden Trusts eingerichtet. 

Nach dem Ausführen des Powershell-CmddLets zur Konfiguration der Föderierung hat sich herausgestellt, dass ein neuer Trust erstellt wird. Zusätzlich zu den Tenant spezifischen Relying Party Trusts wird der Standard Relying Party Trust mit der oben angesprochenen Claim Rule, eingerichtet. Wenn man diesen wieder löscht (ich habe ja schon zwei Relying Party Trusts mit der Tenant spezifischen Metadata XML) funktioniert nichts mehr.

Warum?

Nun ja, Microsoft bietet zwar die Tenant spezifischen Metadata XML an, allerdings aus einem anderen Grund und zwar für Multi-Tenant Apps die gezielt nur spezifische Azure AD Tenants eingebunden haben und so nicht (zumindest theoretisch) sämtlichen Azure AD Identitäten Zugriff erlauben.

Wenn man sich den wtrealm Claim in der URL anschaut (kommend vom Azure oder Office 365 Login Portal an den ADFS), merkt man wo das eigentliche Problem ist. Während das Attribut username in der URL den Username, welcher der User in den Office 365 oder Azure Portal eingegeben hat liefert, sendet Microsoft standardmäßig (und nicht änderbar!) als wtrealm das Attribut urn:federation:MicrosoftOnline. Dieses Attribut wird mit dem NameIdentifier im ADFS gemappt. Der NameIdentifider Wert muss innerhalb der ADFS Umgebung „unique“ sein. Das bringt die zwei folgenden Probleme mit sich:

  1. Da der Wert „unique“ sein muss, kann nicht ein zweiter Trust aufgebaut werden
  2. Die Tenant spezifischen Trusts haben zwar unterschiedliche NameIdentifider Werte, allerdings schickt das Azure oder Office 365 Login Portal (im Backend nachher Azure AD) nicht den Tenant spezifischen NameIdentifider (sts-windows.net/{TenantID}) sondern den globalen Wert (urn:federation:MicrosoftOnline)

Ergebnis: Alles muss über einen Relying Party Trust abgewickelt werden!

User Friendly Home Realm Discovery

Beim Hinzufügen eines zusätzlichen Claims Provider zum ADFS Server, ändert sich auch die Home Realm Discovery Seite bei ADFS. Dies hat Auswirkung auf die User Experience. Dabei wird zwischen zwei verschiedene Authentifizierung unterschieden.

Bei passiver (Meist Browser-based) Authentifizierung wird der User standardmäßig vor die Wahl gestellt, ob er sich mittels Claims Provider 1 oder Claims Provider 2 authentifizierenden möchte. Thick Clients von Microsoft unterstützen ab Office 2013 mit dem Update „Modern Authentication/ADAL“ die Möglichkeit der passiven Authentifizierung.   

Bei aktiver Authentifizierung ist der Client nicht „SSO/ADFS-Aware“. Deshalb verbindet sich Azure AD (On-behalf-Of User/Client), sobald solch ein Request aufschlägt, zum ADFS Server bzw. Proxy. Beispiele wo eine solche Form der Authentifizierung genutzt wird sind: Exchange Active Sync (EAS) und der Outlook 2010/Lync Thick Client.

Mehr zum Thema Aktive/Passive Authentifizierung kann hier und hier gefunden werden.

Die Art wie die Home Realm Discovery Seite sich verhält kann mittels Powershell so verändert werden, dass nur ein Claims Provider ausgewählt werden kann bzw. das gleich an Claimsprovider x verwiesen wird (indem man den Relying Party Trust konfiguriert bzw. Argument ergänzt). Wie so etwas zu konfigurieren ist, kann man sehr gut hier nachlesen. In dem Kunden Use Case wird allerdings nur ein Relying Party Trust verwendet und somit scheiden sämtliche Wege die Home Real Discovery über PowerShell zu automatisieren aus.

Letze Chance: Java Script

Die letzte Chance noch eine automatisierte Home Realm Discovery hinzubekommen erinnert an ADFS 2.0 Zeiten. Nun hilft nur noch Java Script weiter. Seit ADFS 3.0 basiert die ADFS Website nicht merh auf IIS . Sämtliche Webserver-Daten wurden in eine DLL ausgelagert.

Doch nur nicht Aufgeben:
Es gibt weiterhin die Möglichkeit das ADFS-Theme (u.a. die Home Realm Discovery Seite) zu exportieren und durch ein neues zu ersetzen. Bei dem Export Vorgang erhält man Zugriff auf sämtliche HTML Seiten und auch auf die JavaScript Datei „onload.js“ (die beim Start geladen wird).

Mit wenigen Zeilen Javas Script (am Ende der Datei) kann das gewünschte Ergebnis erreicht werden. In dem Code wird geprüft ob in der URL die Domain „firstdomain.de“ gefunden wird und wenn ja wird ein Redirect auf den SAML IdP ausgeführt, wenn nicht wird der AD Claims Provider verwendet:

//Check domain in url and act accordingly

var locationUrl = window.location.href;

var locationUrlToLower = window.location.href.toLowerCase();

var result = /azuredomain.de/.test(locationUrlToLower);

if (result == true)

    //URL to redirect the user to either AD or to my SAML IdP

    {

        var myRedirectURL = locationUrl + "&RedirectToIdentityProvider=my.SAMLIdP.com";

        window.location.href = myRedirectURL;

    }

else

     {    

HRD.selection('http://adfs.mydomain.de/adfs/services/trust');

     }

Authentifizierungs-Requests des Typs „Aktiv“ sollten hierbei nicht beeinflusst werden, da sich die Domains unterscheiden anders sind und die Office 365 Domain nicht beeinflusst wird. 
Mehr Infos und Anleitungen zum Manipulieren der Home Realm Discovery Seite findet man hier.

Ich hoffe der Blog war interessant und man konnte etwas mitnehmen!

Viele Grüße,

Lennart 

Tags: Azure, Azure AD, ADFS, Home Realm Discovery

E-Mail