ADFS und Shibboleth

Der Windows Service ADFS stellt für Authentifizierte Benutzer entsprechenden Tokens aus, damit diese sich an anderen Applikationen wie Office 365 aber auch Sales Force u.a. anmelden können. , Für die Authentifizierung in Office 365 ist ADFS immer dann ratsam. Allerdings ist ADFS nicht der einzige "Token-Service". Bei dem ein oder anderen Produkt und Service fällt der Name "Shibboleth" als Token Provider.

Was ist Shibboleth?

Laut https://shibboleth.net/about/ ist es ein „OASIS Security Assertion Markup Language (SAML)” und damit ziemlich gut mit ADFS vergleichbar. Es gibt also Applikationen, die SAML-Tokens zur Anmeldung akzeptieren und dazu passende mit Sibboleth einen Service, der solche SAML-Token ausstellt. Eigentlich ist es nichts anderes, als was ADFS auch macht.

Technisch ist Sibboleth eine "Open Source", die in Java geschrieben ist und von einem Administrator auf einem Server installiert wird. Der Sibboleth-Service nutzt dann seinerseits einen Authentifizierungsquelle, um die Anmeldung des Anwender zu verifizieren und erst dann ein Token auszustellen. Analog zu ADFS öffnet der Sibboleth-Service den Port 443 und reagiert auf Anfragen per HTTPS. Es gibt sogar einen eigenen Windows Installer (Siehe https://wiki.shibboleth.net/confluence/display/IDP30/WindowsInstallation) der sich per LDAP mit einem Dienstkonto sogar gegen das Active Directory authentifizieren kann.

ADFS oder/und Sibboleth

Man können nun fragen, warum man zwei Produkte installieren sollte, wenn beide doch quasi die gleichen Funktionen bereitstellen. Und tatsächlich ist die Frage berechtigt, denn beide Produkte erstellen SAML-Tokens. Maßgeblich ist aber nicht der Service sondern die Applikation, die an ADFs oder Sibboleth eingebunden werden soll. So gibt es durchaus kleine aber gemeine Unterschiede bei der Bereitstellung der Dienste.

Es gibt durchaus einige Drittprodukte, die eine Integration von Sibboleth anbieten aber mit ADFS eben nicht genauso einfach arbeiten wollen oder einige weitere Kniffe erforderlich sind. Das scheint umso mehr der Fall zu sein, je mehr die Produkte ihrerseits auf "Open Source" basieren und natürlich zuerst einmal Sibboleth integrieren. ADFS bekommt man ja nur auf Windows Servern mit einem Active Directory. Das ist in Firmen zwar meist eh da aber eben lizenzpflichtig. Insofern kann ich den ein oder anderen Entwickler schon verstehen, der erst mal Sibboleth umsetzt und testet.

Das ist aber gar nicht schlimm, denn oft ist Sibboleth nur der erste Schritt und sobald jemand mit installiertem Active Directory und für Office 365 ebenfalls bereitgestellten ADFS-Service die Lösung umsetzen will, wird es sehr schnell auch einen Weg geben. Eine Möglichkeit besteht z.B. darin, dass der Sibboleth-Service seinerseits als "Relying Party Trust" in einem ADFS-Service eingebunden wird. eine Applikation, die z.B. in der Cloud betrieben wird und eigentlich nur Sibboleth kann, kann problemlos auf einen ebenfalls in der Cloud mit betriebenen Sibboleth-Service zugreifen, der seinerseits aber gar nicht direkt per LDAP auf das Active Directory geht, sondern den  vorhandenen ADFS-Service nutzt. Auch der umgekehrte Weg ist möglich, dass ADFS seinerseits einen Sibboleth-Service als STS verwendet.

Natürlich können Sie auch parallel neben dem ADFS-Service auch noch einen Sibboleth-Service mit einem eigenen DNS-Namen betreiben.

Aufgrund der Unterschiede ist es aktuell in einigen Fällen leider noch nicht möglich mit einem ADFS-Service eine 100% kompatible Bereitstellung von SAML-Tokens und Federation Metadata zu liefern, die eine Integration von Sibboleth bereitstellt.

3rd Party Apps und SAML-Services

Sie sollten aber nicht zu schnell aufgeben, wenn eine Applikation erst mal nur eine Unterstützung für Sibboleth verspricht. Ein Versuch ist es durchaus wert. dieser Applikation ein ADFS-Token vorzuwerfen. Vielleicht funktioniert es ja mit der ein oder anderen Anpassung in der ADFS-Konfiguration für diesen "Relying Party Trust" oder einer Anpassung in der Applikation. Meist beschreiben Applikationen sogar beide Wege.

Wer nutzt Shibboleth?

Der Einsatz von Shibboleth mit Microsoft 365 ist gar nicht einmal so selten. Sie "sehen" es natürlich nicht sofort aber am Aussehen der Anmeldeseite unterscheiden sich klassische Windows ADFS-Server schon von anderen Authentication Servern, da ein Shibbolleth Admin sicher nicht die Zeit aufwendet, genau wie ein Windows ADFS-Service auszusehen. Wer was einsetzt, ist gut zu sehen. Einfach im Gast/privaten Browser auf „https://outlook.office.com“ gehen und einen beliebigen Userpart und die fragliche Domain angeben, z.B.

user@uni-bamberg.de
user@tu-dresden.de

Einige Universitäten haben sogar schöne Dokumentationen bereitgestellt:

Aber auch auf dem Atlassin Bereich von shibboleth gibt es entsprechende Anleitungen

Konfiguration

Ich bin primär in der Windows Welt zuhause, auch wenn ich durchaus mit Linux-Systemen umgehe. Allerdings bin ich kein Shibboleth-Admin und mal eben so baut man sich auch keine Testumgebung auf. Daher sind die folgenden Bausteine Auszüge aus Umsetzungen bei Kunden und Recherchen im Internet von unterschiedlichen Versionen. Bitte recherchieren Sie selbst die aktuellen Möglichkeiten ihres Shibboleth-Service. Mittlerweile gibt es von Microsoft ein sehr umfangreiches Dokument:

Office 365 Single Sign-On with Shibboleth 2 whitepaper
https://www.microsoft.com/en-us/download/details.aspx?id=35464

Auf der Seite von ExtraID muss ich die entsprechende UPN auf "Federation" setzen. Das geht per AzureAD/MSOnline PowerShell. Sie benötigen vorab das Signing-Zertifikat des IDP und natürlich die Hostnamen.

Diese PowerShell bezeichnet die "passive Anmeldung", die nicht mehr genutzt werden sollte.

$upndomain = "<UPDOmain>"
$idpHost="<Hostname des IDP>"
$fedBrandName="<Name der Organisation> Shibboleth"
$idpurl = "$idpHost/idp/profile/SAML2/POST/SSO"
$ecpUrl = "$idpHost/idp/profile/SAML2/SOAP/ECP"
$uri = "$idpHost/idp/shibboleth"
$logoutUrl = "$idpHost/idp/profile/SAML2/POST/SLO" 

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("idp_signing.crt")
$certData = [system.convert]::tobase64string($cert.rawdata)

Set-MsolDomainAuthentication `
   -DomainName $upndomain `
   -federationBrandName $FedBrandName `
   -Authentication Federated `
   -PassiveLogOnUri $idpurl `
   -SigningCertificate $certData `
   -IssuerUri $uri `
   -ActiveLogOnUri $ecpUrl `
   -LogOffUri $logoutUrl `
   -PreferredAuthenticationProtocol SAMLP

Get-MsolDomainFederationSettings -DomainName $upndomain


Convert-MsolDomainToFederated -SupportMultipleDomain -DomainName $upndomain

Danach haben die in EntraID die Einstellungen vorgenommen, dass eine Anmeldung an Microsoft 365 mit der entsprechenden UPN auf die durch die "$idphost" und "$idpurl" referenzierte Seite umgeleitet wird. Dort muss dann natürlich Shibboleth den Request annehmen, die Authentifizierung durchführen und den Client mit einem Rücksprung zu EntraID versehen. EntraID prüft dann das signierte SAML-Token anhand des bereitgestellten Signing Zertifikats und übernimmt dann die Anmeldeinformation, um seinerseits dann weitere EntraID-Tokens für die entsprechenden Dienste auszustellen.

Die Konfiguration auf dem Shibboleth-Server habe ich noch nicht beschrieben.

Shibboleth Logoff

Wenn ein Anwender sich per Shibboleth authentifiziert hat und seine Arbeit in Microsoft 365 erledigt hat, dann sollte er sich natürlich auch Abmelden. Dazu gibt es in jedem Microsoft 365 Portal oben rechts das Profilbild mit einem Abmelde-Menü. Der Anwender klickt auf diesen Button und im Hintergrund startet Microsoft den Logout-Prozess.

Es reicht aber nun nicht, wenn die Applikation selbst ihr Application-Cookie löscht, denn dann kann ein anderer Anwender über den "Zurück-Button" die Sitzung wieder aufnehmen. Das EntraID-Token aber auch das Shibboleth-Token sind im Browser noch vorhanden. Diese Information kann aber nur von der Webseite selbst gelöscht werden, die diese Daten gesetzt hat. Daher triggert die Abmeldung auch einen Rücksprung zu login.microsoftonline.com und von dort weiter zum lokalen Shibboleth-Server.


Quelle: https://learn.microsoft.com/de-de/entra/identity-platform/single-sign-out-saml-protocol

Das Bild beschreibt zwar nur die Abmeldung an der Applikation und Microsoft EntraID aber mit Shibboleth wird der Client dann von Microsoft Entra ID zur konfigurierten Logout-URL gesendet. Der Client bekommt dabei eine "NameID" mit, die bei Entra ID in der Regel aus dem UPN gebildet wird. Shiboleth erwartet hier aber wohl eine "Persistent ID", die er bei der Anmeldung vergeben hat.

Als Folge kann der POST auf die konfigurierte Logout-URL nicht zugeordnet werden und die Abmeldung funktioniert nicht.

Interessanterweise haben mehrere Universitäten genau dieses Problem in ihren Anleitungen beschrieben und (noch) keine Lösung gefunden. Stattdessen sollte der Nutzer die manuelle Logout-URL des Shibboleth-Servers per Browser aufrufen, um die Abmeldung abzuschließen oder im Browser die Cookies manuell löschen und den Browser komplett neu zu starten.

Von der Universität Konstanz habe ich folgenden Auszug aus einer Beschreibung bekommen, die das Problem dort gelöst hat:

Auf dem Shibboleth-Server musste ein „Relying Party Trust" konfiguriert werden, welcher den Request des Clients nach Authentifizierung mit einem SAML-Token beantwortet wird. Der Request enthält dazu folgende Anforderung:

<samlp:AuthnRequest
	xmlns="urn:oasis:names:tc:SAML:2.0:metadata"
	ID="011d7c44-ffec-4923-adc5-5efc0521118d"
	Version"2.0" IssueInstant="2025-01-01T00:00:00.000Z"
	xrnlns:sarnlp="urn:oasis:names:tc:SAML:2.O:protocol">
   <Issuer xmlms="urn:oasis:names:tc:SAML:2.0:federation:MicrosoftOnline</Issuer>
   <samlp:NameIDPolicy 
Format="urn:oasis:names:tc:SAML:2.0:nameid-format persistent"/>
</samIp:AuthnRequest>

Damit fordert der Client ein SAML-Token für den Service „urn:federation:MicrosoftOnline" an. Das Token muss das Feld „Nameid-format:persistent" enthalten, welches mit dem UPN in Entra ID übereinstimmen muss.

Über das Hilfsmittel einer "custom-reuse condition" für das Kennwort wird verhindert, dass ein User nach einem fehlerhaften Logout beim Druck auf den Login-Button in Verbindung Shibboleth SSO mit sofort wieder angemeldet wird. Zwei Dateien sind dabei anzupassen:

  • Datei: /opt/shibboleth-idp/conf/global.xml
    Zuerst definieren wir eine CustomReuseCondition
<bean id="CustomReuseCondition" parent="shibboleth.Conditions.NOT">
  <constructor—arg>
    <bean parent="shibboleth.Conditions.RelyingPartyId" c:candidate="urn:federation:MicrosoftOnline" />
  </constructor—arg>
</bean>
  • Datei: /opt/shibboleth-idp/conf/authn/authn.properties
    Dann wechseln wir von der shibboleth.Conditions auf die CustomReuseCondition 
#idp.authn.Password.reuseConditIon=shibboleth.Conditions.TRUE
idp.authn.Password.reuseCondition=CustomReuseCondition

Damit sollte nun bei einem Logout keine automatische erneute Anmeldung in Verbindung mit Shibboleth SSO möglich sein.

Weitere Links