Microsoft Entra ID bietet mit External Identities die Möglichkeit andere Entra ID Tenants, Social Logins wie auch externe SAML2/WS-Fed Identity Provider anzubinden. Im B2B (Business to Business) Umfeld ist letzteres sehr interessant um mit anderen Firmen gemeinsam an Ressourcen arbeiten zu können, ohne deren Identitäten pflegen zu müssen. Dadurch, dass die andere Firma sich an ihrem eigenen Identity Provider anmeldet gibt es auch für sie einige Vorteile wie zum Beispiel Single Sign On und die Hoheit über die Mover-Joiner-Leaver Prozesse zu behalten. Im folgenden Beitrag zeige ich wie eine solche Federation mit den zwei Produkten Keycloak (Open Source) und Auth0 (SaaS Lösung) mit den minimal Einstellungen konfiguriert werden kann. Andere Produkte welche SAML2 oder WS-Federation unterstützen funktionieren auch solange die folgenden Punkte eingehalten werden:

  • NameID Format muss urn:oasis:names:tc:SAML:2.0:nameid-format:persistent entsprechen und als Wert muss die Email Addresse verwendet werden
  • Der Claim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress muss in der SAML Assertion mitgeschickt werden, ebenfalls mit der Email Adresse als Wert
  • Signed Requests müssen deaktiviert werden weil sie aktuell noch nicht unterstützt werden https://learn.microsoft.com/en-us/entra/external-id/direct-federation

Keycloak

Keycloak ist eine verbreitete Open Source Identity Provider Software, die 2014 durch die Firma Red Hat (WildFly) veröffentlicht wurde. Sie wurde in Java geschrieben, ist durch Extensions erweiterbar und unter der Apache License 2.0 veröffentlicht.

Die Konfiguration von Keycloak für die Nutzung als External Identity Provider in Microsoft Entra ID läuft folgendermassen ab

  1. Im Keycloak Realm wird ein neuer Client vom Typ SAML angelegt. Die ClientID entspricht der EntityID welche Entra ID im SAML AuthNRequest schickt https://login.microsoftonline.com/<TenantID>/, wichtig ist der abschliessende / ansonsten meldet Keycloak einen invalid request. keycloak-client
  2. Anschliessend wird auf Next geklickt und im anschliessenden Formular auf Save
  3. Unter SAML capabilities wird das Name ID format von username auf email geändert keycloak-nameIDFormat
  4. Im Reiter Advanced wird unter Assertion Consumer Service POST Binding URL der Wert https://login.microsoftonline.com/login.srf eingetragen keycloak-acs
  5. Als nächstes wird unter Client scopes das scope role_list entfernt und anschliessend auf das -dedicated scope geklickt. Dort wird mit Configure a new mapper der Mapper User Attribute Mapper for NameID hinzugefügt.
  6. Der Name kann frei gewählt werden, wichtig ist, dass das Name ID Format den Wert urn:oasis:names:tc:SAML:2.0:nameid-format:persistent beinhaltet und als User Attribute wird email verwendet
  7. Nun wird noch ein Mapper vom Typ User Attribute hinzugefügt um den Claim emailaddress in der SAML Assertion hinzuzufügen, welcher von Microsoft Entra ID erwartet wird keycloak-emailaddress-claim
  8. Als letzter Punkt müssen Signed Requests deaktiviert werden, weil Microsoft Entra ID dies noch nicht unterstützt. Diese Einstellung ist unter Keys zu finden keycloak-request-signing
  9. Das Metadata Dokument ist unter Realm settings -> Endpoints zu finden. Die URL entspricht dem Format https://<Keycloak>/realms/<Realm>/protocol/saml/descriptor

Auth0

Auth0 ist eine anpassungsfähige SaaS Lösung für Authentication & Authorization, welche im Mai 2021 von der Firma Okta übernommen wurde. Sie bietet Software Development Kits (SDK) für eine Vielzahl von Programmiersprachen und untertützt Standart Protokolle wie OpenID Connect, OAuth2, SAML2 und WS-Federation.

  1. Unter Application wird über + Create Application eine neue Applikation hinzugefügt. Als application type wird Regular Web Applications ausgewählt
  2. Im Reiter Addons wird SAML2 WEB APP aktiviert, das Konfigurationsfenster öffnet sich und der Reiter Settings wird angewählt auth0-saml
  3. Als Application Callback URL wird https://login.microsoftonline.com/login.srf und bei den Settings folgender JSON Inhalt eingetragen
1
2
3
4
5
6
7

{
  "mappings": {
    "user_id": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
    "email": "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"
  },
  "nameIdentifierFormat": "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
}

auth0-saml-settings 4. Die Metadaten können über den Reiter Settings -> Advanced Settings -> Endpoints -> SAML Metadata URL in der Applikation heruntergeladen werden

Entra ID

☝️ Wenn sich der Domain Namen der User (z.B [email protected]) des federierten Identity Provider von dem Passive authentication endpoint (z.B idp.irbe.ch) unterscheidet, muss vorgängig ein TXT Record im DNS erstellt werden der folgendermassen aussieht: companyKeycloak.irbe.ch. IN TXT "DirectFedAuthUrl=https://idp.irbe.ch/realms/irbe/protocol/saml"

  1. Im Menu unter Identity -> External Identities wird All identity providers geöffnet und Keycloak hinzugefügt entraid-keycloak
  2. Nun müssen die Benutzer der federierten Domäne als Guests in den Microsoft Entra ID Tenant eingeladen werden. Für einzelne Benutzer oder zu Testzwecken kann dies im Portal erledigt werden, bei Massenimport biete sich der Bulk import über eine CSV Datei oder das Graph API an.
  3. Das Setup kann zum Beispiel über MyApps getestet werden, indem die primäre Tenant Domain hinten angefügt wird https://myapps.microsoft.com/<TenantName>.onmicrosoft.com

Schlusswort

Dieser Beitrag soll zeigen, wie einfach es ist eine Federation zu Microsoft Entra ID mit anderen Anbietern einzurichten. Der nächste Schritt wäre dann entsprechende Conditional Access Policies zu erstellen um zum Beispiel Multifaktor Authentifizierung zu erzwingen und den Zugriff auf die Firmeninternen Ressourcen einzugrenzen. Wichtig ist auch die Lizenzierung der Guests entsprechend den Bedürfnissen (1:5 Modell vs. Monthly Active Users) zu konfigurieren. Microsoft hat dazu einen Artikel veröffentlicht https://learn.microsoft.com/en-us/entra/external-id/external-identities-pricing