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 so gar schöne Dokumentationen bereitgestellt

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

Weitere Links