Shibboleth

Shibboleth
Basisdaten
Entwickler	Shibboleth Konsortium[1]
Aktuelle Version	5.0.0 (IdP (Windows)) 13.09.2023[2] 5.0.0 (IdP (Linux)) 13.09.2023[3] 3.4.1.4 (SP) 11.10.2023[4] 1.2.1 (EDS) 28.01.2019[5]
Betriebssystem	Microsoft Windows, Linux
Programmiersprache	Java (IdP), C++ (SP)
Lizenz	Apache-Lizenz, Version 2.0[6][7]
shibboleth.net

Mit Shibboleth sind mehrere verschiedene Software-Komponenten gemeint, über die Benutzer im Webbrowser auf geschützte Webanwendungen zugreifen können. Dabei müssen sie sich in einer Browser-Sitzung nur einmal anmelden (Single Sign-on), um Ressourcen verschiedener Anbieter zu nutzen. Mit Shibboleth ist verteiltes Single Sign-on möglich: Die Benutzer, die auf eine geschützte Webanwendung zugreifen möchten, müssen ihre Nutzerkonten nicht bei einer zentralen Stelle haben, sondern sie können sie bei unterschiedlichen Einrichtungen haben, z. B. bei Hochschulen. Auch die zur Verfügung stehenden Webanwendungen müssen nicht alle von derselben Stelle betrieben werden. Die Shibboleth Software-Komponenten sind eine Möglichkeit, verteiltes Web Single Sign-on aufzubauen.

Die Shibboleth-Komponenten implementieren hauptsächlich den SAML 2.0-Standard, es werden jedoch auch das CAS-Protokoll^[8] und – seit 2020 – OpenID Connect^[9] unterstützt.

Die Entwicklung von Shibboleth startete im Jahr 2000 bei Internet2.^[10] Inzwischen wird die Software vom Shibboleth Consortium entwickelt, das sich aus Mitgliedsbeiträgen von Firmen, nationalen Forschungsnetzen und einzelnen Hochschulen finanziert.^[11][12] Alle Komponenten stehen unter der Apache-Lizenz und sind damit Freie Software.^[13]

Etymologie

Der Projektname stammt vom hebräischen Wort Schibboleth (hebr. שבולת) und bedeutet wörtlich „Strömung“, „Strom“ oder „Flut“. Im jüdischen Tanach (dem christlichen Alten Testament) im Buch der Richter 12,5–6 wird geschildert, wie ein Grenzposten an einer Furt alle Passanten auffordert, dieses Wort auszusprechen. Aufgrund der unterschiedlichen Aussprache diesseits und jenseits der Grenze wird zwischen Freund und Feind unterschieden. Deshalb wird das Wort heute in der Bedeutung von „Kennwort“ oder „Codewort“ verwendet. Vgl. in der Bibel Buch Richter 12,5f. wonach mit der falschen Aussprache dieses Wortes die Männer von Gilead 42.000 fliehende Efraimiter enttarnten und ermordeten.

Das Logo von Shibboleth ist ein Greif.

Komponenten

Das Shibboleth Consortium entwickelt drei Software-Komponenten, die unabhängig voneinander eingesetzt werden können. Sie sind Implementierungen von Standards wie SAML 2.0 und sind damit interoperabel zu anderen standardkonformen Softwarelösungen. Damit ein Loginvorgang funktionieren kann, werden mindestens ein Identity-Provider und ein Service-Provider benötigt, die sich an die gleichen technischen Spezifikationen halten. Es kann, muss jedoch nicht auf beiden Seiten Shibboleth eingesetzt werden.

Identity-Provider (IdP)

Der Identity Provider (IdP) befindet sich bei der Heimateinrichtung. Dort greift er in der Regel auf ein Identitätsmanagement-System, z. B. einen Verzeichnisdienst zu, in dem die Nutzerkonten der Einrichtung gepflegt werden. Bei einem Loginvorgang prüft der IdP gegen dieses Identitätsmanagement-System (IdM), ob die Nutzerkennung bekannt ist und die Zugangsdaten stimmen. Ist dies der Fall, so ist die Person authentifiziert.

Darüber hinaus hat der Identity Provider detaillierte Informationen über die Person. Sie werden in Form von standardisierten Attributen konfiguriert. Die Informationen dafür können aus dem IdM geholt oder direkt im IdP generiert werden. Beispiele für gängige Attribute sind givenName (Vorname), sn (Nachname) oder mail (E-Mail-Adresse). Für das Hochschul- und Forschungsumfeld existieren spezielle Attributschemata, um etwa Zugriffsberechtigungen oder Organisationszugehörigkeiten der Nutzenden ausdrücken zu können. Beispiele für solche Attribute sind eduPersonEntitlement (für Berechtigungen) oder eduPersonAffiliation (für Gruppenzugehörigkeiten innerhalb von Hochschulen).

Im Identity Provider werden Regeln festgelegt, welche Attribute über die Personen an welche Service Provider herausgegeben werden dürfen. Die Nutzenden müssen der Freigabe dieser Informationen für jeden Dienst einmalig zustimmen.

Service-Provider (SP)

Der Service Provider (SP) befindet sich beim Anbieter. Dort sitzt die Software i. d. R. vor der eigentlichen geschützten Webanwendung, beim Shibboleth SP in Form eines Moduls für die Webserver Apache oder IIS. Sie nimmt bei einem Loginvorgang die vom Identity Provider übertragenen Attribute entgegen und prüft gegen ihre eigenen Regeln, ob die Attribute und ggf. auch die genauen Werte dieser Attribute für einen Zugriff ausreichen. Ist dies der Fall, so autorisiert die Service Provider-Software den Zugriff.

Einrichtungsauswahl / Embedded Discovery Service (EDS)

(früher WAYF Where are you from?)

kann optional vom Betreiber eines Service Providers eingesetzt werden, um dem Benutzer die Auswahl seiner Heimateinrichtung zu ermöglichen

Funktionsweise

Die Funktionsweise von Shibboleth lässt sich am einfachsten anhand des folgenden Szenarios erklären:

Authentifizierung (Wer bist du?)

Eine Person möchte auf eine geschützte Ressource zugreifen. Der Anbieter nimmt die Anfrage entgegen und prüft, ob die Person in ihrem Webbrowser bereits über einen IdP angemeldet ist. Wenn nicht, wird sie zu einem Discovery Service weitergeleitet. Der Discovery Service bietet eine Auswahl von Einrichtungen an. Die Person wählt ihre Heimateinrichtung aus und wird dann zum Identity Provider dieser Einrichtung umgeleitet. Dort authentifiziert sie sich, z. B. mit Nutzerkennung und Passwort. Der Identity Provider der Heimateinrichtung stellt daraufhin die Attribute über die Person zusammen, die er aufgrund seiner Filterregeln an diesen speziellen Service Provider herausgeben darf. Er präsentiert die zu übertragenden Informationen der Person zur Zustimmung oder Ablehnung. Im Fall von SAML 2.0 verpackt der IdP diese Informationen nach erfolgter Zustimmung in eine verschlüsselte SAML-Assertion und leitet den Benutzer zum Anbieter zurück. Im Fall von OpenID Connect 1.0 werden stattdessen ein Access Token, ein ID Token und ggf. ein Refresh Token mit entsprechenden Claims übertragen.

Autorisierung (Was darfst du?)

Auf der Seite des Dienstanbieters nimmt die Service Provider-Software die übersendeten Informationen entgegen, prüft nach ihren konfigurierten Regeln, ob sie für einen Zugriff auf die gewünschte Ressource ausreichen, und gewährt Zugriff oder lehnt ihn ab.

Einsatz

Verteiltes SAML-basiertes Web Single Sign-on wird vor allem im Bereich Wissenschaft, Forschung und Lehre eingesetzt. Hier hat besonders der Shibboleth Identity Provider eine Vorrangstellung gegenüber anderen Software-Lösungen^[14]: Der IdP war nicht nur die erste, sondern bis heute auch die umfassendste Implementierung eines SAML-IdP. Es stehen eine Reihe von Plugins und Modulen zur Verfügung^[15], es können eigene Login-Flows konfiguriert oder selbst programmiert werden. Überdies sichert die Finanzierung des Konsortium durch Mitgliedsbeiträge die langfristige Weiterentwicklung der Software.

Im Kontext von Hochschulen und Forschungseinrichtungen sind Shibboleth-Produkte, aber auch andere SAML-fähige Software, deshalb sehr verbreitet, weil der SAML-Standard den Bezug auf gemeinsame vertrauenswürdige Metadaten vorsieht: Einrichtungen und Dienstanbieter, die sich auf gemeinsame Regeln einigen, können sich in einer multilateralen Föderation zusammentun. Eine vertrauenswürdige Organisation stellt dann regelmäßig digital signierte Informationen darüber bereit, welche IdPs und SPs aktuell an der Föderation teilnehmen. Im Fall von SAML sind dies Metadatensätze im XML-Format. Jedes dieser Systeme holt sich ebenfalls diese Metadaten, prüft die Signatur und kommuniziert nur mit Gegenstellen, die auch von Föderationsteilnehmern betrieben werden. Dies reduziert den Aufwand des Metadatenaustausches, der ohne die Föderation zwischen allen Teilnehmenden selbst geschehen müsste.

Solche Föderationen können sowohl hausintern, als auch auf Bundesländer-Ebene, national oder international aufgebaut werden. Beispiele für Länderföderationen sind im deutschen Hochschulkontext das baden-württembergische bwIDM^[16] oder das nordrhein-westfälische IDM.nrw^[17]. Identity-Föderationen auf nationaler Ebene sind in Deutschland die DFN-AAI, die vom Verein zur Förderung eines Deutschen Forschungsnetzes e. V. (DFN-Verein) betrieben wird, in der Schweiz SWITCHaai und in Österreich die ACOnet Identity Federation. Unter dem Markennamen eduGAIN betreibt GÉANT zudem einen Zusammenschluss der nationalen Föderationen zu einer sogenannten Interföderation. Der Vorteil an der Interföderation ist, dass sich Personen aus einer teilnehmenden Hochschule in einem Land mit ihrem Hochschulkonto auch bei Dienstanbietern im Ausland einloggen können, wenn der Service Provider über die dortige Föderation an eduGAIN teilnimmt.

Weblinks

• ACOnet Identity Federation
• Konzeptuelle und technische Erklärung in drei Schwierigkeitsstufen, Online-Demo der SWITCH-AAI.
• Projekt verteilte Authentifizierung, Autorisierung und Rechteverwaltung (AAR) an der Albert-Ludwigs Universität Freiburg
• SWITCHaai
• Offizielle Website
• Deutsche Föderation DFN-AAI
• Vollständige Liste der Föderationen (Research and Education)

Einzelnachweise

1. ↑ www.shibboleth.net. (abgerufen am 18. Juli 2023).
2. ↑ Release Notes. Abgerufen am 18. Oktober 2023 (englisch). 
3. ↑ Release Notes. Abgerufen am 18. Oktober 2023 (englisch). 
4. ↑ Release Notes. Abgerufen am 18. Oktober 2023 (englisch). 
5. ↑ Release Notes. Abgerufen am 19. Juli 2023 (englisch). 
6. ↑ shibboleth.atlassian.net. (abgerufen am 18. Juli 2023).
7. ↑ shibboleth.atlassian.net. (abgerufen am 18. Juli 2023).
8. ↑ Konfiguration von CAS im Shibboleth Identity Provider
9. ↑ Konfiguration von OpenID Connect im Shibboleth Identity Provider
10. ↑ Website des Shibboleth Consortiums
11. ↑ Informationen zur Mitgliedschaft im Shibboleth Consortiums
12. ↑ Mitgliederliste des Shibboleth Consortiums
13. ↑ Lizenzhinweis in der Online-Dokumentation
14. ↑ DFN-Vortragsfolien von Juni 2023 (pdf, siehe S. 4)
15. ↑ Dokumentation der Plugins für den Shibboleth IdP
16. ↑ bwIDM – Föderiertes Identitätsmanagement der baden-württembergischen Hochschulen
17. ↑ idm.nrw - Machbarkeitsstudie föderiertes Identity Management in Nordrhein-Westfalen