- ein modernes Single Sign On (SSO) System
Viele webbasierte Dienste der Humboldt-Universität sind auf eine Authentifizierung ihrer Nutzer und häufig auch auf deren Autorisierung angewiesen. Momentan implementiert jeder Dienst eigene Anmeldefunktionen, was zur Folge hat, dass der Nutzer möglicher Weise mit mehreren verschiedenen Arten zur Anmeldung am Tag konfrontiert wird.
Eine für den Nutzer leichter handhabbare Lösung bietet das Shibboleth SSO System, welches dem Nutzer erlaubt, sich nur einmal je Sitzung zu authentifizieren und innerhalb dieser Sitzung alle an Shibboleth angebundenen Dienste ohne weitere Authentifizierung zu nutzen. Ermöglicht wird diese Funktion durch Technologien des Browsers auf Nutzerseite und der zentralen Authentifizierung im Shibboleth SSO System. Als Sitzung wird dabei der Zeitraum zwischen dem Öffnen des Browsers und dem Schließen der letzten offenen Instanz des Browsers bezeichnet.
Zusätzlich zur Authentifizierung des Nutzers kann das Shibboleth System sogenannte Attribute (Informationen zum Nutzer, die vom Identitätsmanagement bereitgestellt werden) für die Autorisierung des Nutzers an den Dienst liefern. Dazu wird im Shibboleth System vorher einmalig festgelegt, welcher Dienst welche Attribute benötigt. Diese werden unter der Voraussetzung der Zustimmung durch den Nutzer nach erfolgreicher Authentifizierung an den Dienst übertragen. Die eigentliche Autorisierung des Nutzers übernimmt der Dienst auf Grundlage der übertragenen Attribute selbst.
Für den Nutzer ergeben sich folgende Szenarios für den Zugriff auf webbasierte Dienste:
Der Nutzer öffnet seinen Browser und wählt die Adresse des gewünschten Dienstes (Siehe Abbildung 1: 1 Starte Dienst). Auf dem Server des Dienstanbieters, Service-Provider (SP) genannt, leitet das Shibboleth-SP Modul den Browser an den zentralen Shibboleth-Server, dem sogenannten Identity-Provider (IdP) weiter (Abbildung 1: 6 Umleitung), denn nur dieser kennt die Nutzer. Der IdP präsentiert dem Nutzer im Browser die Login-Seite, in die er seinen Nutzernamen und das Passwort eingeben muss (Abbildung 1: 7 Login? und 8 Login.).
Mit Nutzernamen und Passwort schaut der IdP in seine Sammlung von Identitätsdaten (zumeist bereitgestellt von einem Identitätsmanagement), ob ein Nutzer mit dem angegebenen Account und Passwort existiert, wenn ja ist der Nutzer authentifiziert, wenn nein hat er sich vielleicht vertippt und bekommt im Browser die Login-Seite erneut präsentiert.
Ist der Nutzer authentifiziert, legt der IdP eine Shibboleth-Sitzung für den Nutzer an und schreibt die Kennung dieser in ein sogenanntes Browser-Cookie, das wie ein Merkzettel im Browser funktioniert. Für jeden weiteren Dienst, der sich an den IdP wendet, wird dieses Cookie zum Auffinden der Shibboleth-Sitzung und damit zur Authentifizierung anstelle der Login Anfrage benutzt.
Ist die Authentifizierung abgeschlossen, schaut der IdP welche weiteren Informationen zum Nutzer vom aktuellen Dienst benötigt werden. Das sind die sogenannten Attribute. Wieder schaut der IdP in seine Sammlung von Nutzerdaten und liest die Informationen speziell für den authentifizierten Nutzer aus und stellt damit die Liste der geforderten Attribute zusammen.
Damit der Nutzer jederzeit die Kontrolle über die zu übertragenden Informationen hat, muss er der Übertragung der Attribute zustimmen (Abbildung 1: 9 Zustimmung?). Diese Zustimmung kann generell für die Attributlisten jedes beliebigen beteiligten Dienstes erfolgen, oder für die Attributliste eines bestimmten Dienstes einzeln. Dazu präsentiert der IdP dem Nutzer die Liste der aktuell zu übertragenden Attribute mit den entsprechenden Möglichkeiten zur Zustimmung (generell oder für den aktuellen Dienst). Der Nutzer kann seine Zustimmung durch ein Häkchen auf der Login-Seite des IdP jederzeit zurückziehen.
Hat der Nutzer der Übertragung der Attribute zugestimmt, werden diese zusammen mit der Information der erfolgreichen Authentifizierung in eine verschlüsselte Nachricht gepackt, die an den Shibboleth-SP zurück übertragen wird. Hat der Nutzer der Übertragung nicht zugestimmt, bekommt der Shibboleth-SP nur die Nachricht über eine erfolgreiche Authentifizierung zurück (Abbildung 1: 11 Umleitung).
Der Shibboleth-SP Modul packt die Nachricht aus und übergibt dem eigentlichen Dienst die Attribute. Anschließend überträgt der Shibboleth-SP Modul dem eigentlichen Dienst die Kontrolle (Abbildung 1: 12 Dienst!). Der Dienst kann jetzt mit Hilfe der Attribute entscheiden, was der Nutzer an Funktionen bekommt.
Der Nutzer wählt im gleichen Browser die Adresse eines weiteren Dienstes. Der Shibboleth-SP Modul leitet auch in diesem Fall wieder zum IdP weiter. Dieser sieht das Cookie und erkennt die Shibboleth-Sitzung und überprüft, ob diese immer noch gültig ist. Je nach Konfiguration hält eine Shibboleth-Sitzung zwischen einer halben Stunde und einem ganzen Tag. Ist sie nicht mehr gültig, wird wie beim oben beschriebenen ersten Zugriff weiter verfahren. Liegt jedoch eine gültige Sitzung - wie in den meisten Fällen - vor, werden sofort die benötigten Attribute für den aktuellen Dienst zusammengestellt. Die Wege 7 und 8 in Abbildung 1 entfallen in diesem Fall.
Alle weiteren Vorgänge sind identisch zu den beim ersten Zugriff ablaufenden Vorgängen, d.h. auch hier muss der Nutzer wieder der Übertragung der Attribute zustimmen, wobei hier die Zustimmung meist schon vorliegt und damit die Wege 9 und 10 in Abbildung 1 ebenfalls entfallen. Danach geht die Nachricht mit den Attributen wieder an den Shibboleth-SP Modul zurück der sie auspackt und dem aktuellen Dienst übergibt.
In diesem Fall passieren alle diese Prozesse im Hintergrund, ohne dass der Nutzer die Umleitungen bemerkt, da er über den Browser gleich die Seite des Dienstes präsentiert bekommt.
Durch die Organisation mehrerer Einrichtungen (z.B. Universitäten, Hochschulen, Verlage) in Föderationen ist es möglich, Web-Dienste Zugehörigen anderer Institutionen zugänglich zu machen und selbst Web-Dienste anderer Einrichtungen zu nutzen.
Abbildung 1: Shibboleth Anmeldung aus Nutzersicht
Für den Nutzer ist für den Zugriff auf Web-Dienste fremder Einrichtungen innerhalb der Föderation lediglich die Wahl der Heimateinrichtung zu Beginn der Authentifizierung nötig. Die Heimateinrichtung ist die Einrichtung, in der der Nutzer tätig bzw. als Student eingeschrieben ist.
Für den ersten Zugriff innerhalb einer laufenden Sitzung geht also die erste Umleitung vom SP-Modul zum sogenannten Discovery Service (DS) (Abbildung 1: 2 Umleitung). Dieser fragt über eine Seite im Browser den Nutzer nach der Heimateinrichtung (Abbildung 1: 3 Heimateinrichtung?). Diese merkt sich der DS auch in einem Browser-Cookie. In manchen Fällen fragt der DS den Nutzer nicht, sondern gibt die Heimateinrichtung zurück, über den der Nutzer im Internet angemeldet ist (in deren IP-Bereich sich der Nutzer gerade befindet). Dann fallen die Wege 3 und 4 in der Abbildung 1 weg. Hat der DS die Heimateinrichtung, schickt er diese an den SP-Modul zurück (Abbildung 1: 5 Umleitung).
Die weiteren Schritte sind identisch zum Verlauf der Anmeldung ohne Föderation (siehe oben).
Internet2: http://shibboleth.internet2.edu/
DFN-AAI: https://www.aai.dfn.de/