Im Hochschulalltag begegnet uns oft eine breite Auswahl verschiedener Software. Die meisten Hochschulen arbeiten mit mehreren Diensten zusammen, um Lehrenden und Studierenden den Alltag zu erleichtern und ihr digitales Lehrangebot bestmöglich auszuschöpfen. Stellen wir uns nun vor, wir bräuchten für jeden Dienst einen eigenen Zugang. Wir hätten also ein Passwort für Opencast, eines für BigBlueButton, eines für LEIHS und wiederum eines für das LMS unserer Hochschule. Denn jeder dieser Dienste würde über eine eigene Nutzerverwaltung verfügen. Das verwirrt und führt schnell zu Notizzetteln, die am Bildschirm kleben und jedem, der vorbeikommt, den Zugang zu sensiblen Bereichen ermöglichen.
Auch technisch wird es schwierig, wenn viele verschiedene Logins parallel existieren. Vor allem bei zentralen Anforderungen – etwa einer verpflichtenden Zwei-Faktor-Authentifizierung – lässt sich das kaum noch konsistent umsetzen.
Genau dafür gibt es zentrale Logindienste. Sie sorgen dafür, dass die Authentifizierung an einer zentralen Stelle durchgeführt wird und die angebundenen Dienste die benötigten Informationen von dort erhalten. So reicht es aus, wenn Nutzende sich einmal über den zentralen Identity Provider anmelden. Anschließend können sie ohne erneute Anmeldung auf alle verknüpften Anwendungen zugreifen und müssen sich nur noch ein einziges Passwort merken.
Auch eine Zwei-Faktor-Authentifizierung kann zentral aktiviert und für alle angebundenen Dienste genutzt werden. Zudem lassen sich Dienste, die denselben zentralen Login verwenden, technisch leichter anbinden. Wie genau das funktioniert und welche Vorteile das konkret bietet, schauen wir uns im Folgenden genauer an.
Wer in Hochschulen und Bildungseinrichtungen arbeitet, wird beim Thema zentrale Logindienste am ehesten mit Shibboleth in Berührung kommen. Dabei handelt es sich nicht selbst um ein Login-Verfahren, sondern um eine Software-Suite, die Standards wie SAML 2.0 Web Single Sign-On implementiert. Innerhalb des deutschsprachigen Hochschulkontextes ist Shibboleth eines der am weitesten verbreiteten Systeme.
Um zentrale Logindienste nutzen zu können, betreiben die Rechenzentren der Hochschulen einen sogenannten Identity Provider (IdP). Dieser IdP ist die notwendige Voraussetzung, um Dienste wie Opencast, Stud.IP oder andere Anwendungen über Shibboleth anzubinden. Die meisten Hochschulen verfügen bereits über einen solchen IdP, was die Integration neuer Dienste erheblich erleichtert.
Natürlich ist Shibboleth nicht die einzige SSO-Lösung, die Hochschulen einsetzen können. Daneben gibt es beispielsweise den Central Authentication Service (CAS), der in einigen Hochschulen – jedoch seltener im deutschsprachigen Raum – seit Jahren im Einsatz ist.
Ebenfalls relevant ist OpenID Connect (OIDC), eine Authentifizierungsschicht auf Basis von OAuth 2.0. Diese Kombination wird oft in modernen Webanwendungen genutzt und kann ebenfalls SSO-Funktionalität bereitstellen.
Aufgrund der hohen Verbreitung von Shibboleth im Hochschulkontext haben wir uns jedoch dafür entschieden, den Schwerpunkt in diesem Beitrag auf diese Lösung zu legen.
Kaum ein Thema ist im Zusammenhang mit Logindiensten so wichtig wie der Datenschutz. Wie sicher sind zentrale Logindienste – und insbesondere Shibboleth? Schließlich laufen die Authentifizierungsprozesse vieler Dienste über eine zentrale Stelle.
Gehen wir ein praktisches Beispiel durch, um das Ganze anschaulich zu machen: Ein Nutzer meldet sich zum ersten Mal über Shibboleth bei einem angebundenen Dienst an. Der Dienst erkennt, dass er den Nutzer nicht kennt, und leitet den Login-Vorgang an den Identity Provider weiter. Dort authentifiziert sich der Nutzer – beispielsweise mit Benutzername und Passwort plus Zwei-Faktor-Authentifizierung. Wichtig: Das Passwort wird niemals an den Dienst weitergegeben. Stattdessen sendet der IdP eine Signatur mit ausgewählten Attributen, etwa der Hochschulkennung, der E-Mail-Adresse oder weiteren freigegebenen Informationen.
Welche Attribute der Dienst erhält, wird zentral konfiguriert und nur in dem Umfang bereitgestellt, der notwendig ist. Viele Hochschulen nutzen hierfür zusätzlich eine Consent-Funktion, bei der Nutzende der Weitergabe bestimmter Attribute zustimmen können – das ist jedoch optional und hängt von der jeweiligen Einrichtung ab.
Shibboleth basiert auf dem offenen Standard SAML 2.0 (Security Assertion Markup Language). Dieser Standard wurde speziell für föderiertes, domainübergreifendes Single Sign-On entwickelt. Nutzer*innen authentifizieren sich einmal beim Identity Provider und können anschließend – durch diese bestätigte Authentifizierung – weitere Dienste nutzen.
Im Shibboleth-Kontext gibt es zwei zentrale Komponenten: den Identity Provider (IdP) und den Service Provider (SP).
Es gibt zwei typische Wege zur Anmeldung:
Der Wechsel zwischen Dienst und IdP geschieht über Redirects – die meisten Nutzenden nehmen das kaum wahr, weil der Ablauf sehr schnell und einheitlich gestaltet ist.
Ein großer Vorteil: Ein einziger Identity Provider kann mehrere Dienste bedienen – und einzelne Dienste können wiederum mehrere IdPs unterstützen. So ist es möglich, dass z. B. ein Opencast-Server Nutzende verschiedener Hochschulen akzeptiert.
Für Hochschulen existiert außerdem die DFN-AAI-Föderation (Authentication and Authorization Infrastructure). Sie ist kein zentraler Login-Ort, sondern eine föderierte Vertrauensstruktur. Hochschulen registrieren dort ihre IdPs und SPs, sodass Dienste und Einrichtungen gegenseitig auf vertrauenswürdige Metadaten zugreifen können. Das ermöglicht erst die nahtlose Nutzung hochschulübergreifender Dienste.
Authentifizierung bedeutet nicht automatisch auch Autorisierung. Shibboleth selbst kümmert sich um die Authentifizierung und die Bereitstellung von Attributen. Die eigentliche Autorisierung – also welche Rechte und Rollen ein Nutzer in einem bestimmten Dienst besitzt – entscheidet der Service Provider beziehungsweise das jeweilige Anwendungssystem.
Bei der Authentifizierung prüft der IdP, ob der Nutzer derjenige ist, für den er sich ausgibt. Der Dienst sieht anschließend die bereitgestellten Attribute (z. B. Rolle, Status oder Gruppenzugehörigkeit) und ordnet daraufhin die entsprechenden Rechte zu. Studierende haben in Opencast also andere Rechte als Lehrende – aber diese Zuweisung findet im Dienst statt, nicht zentral in Shibboleth.
