CMS Journal
Nr. 34
Mai 2011
Service
Metadaten
Hinweise
Weitere Artikel aus dem cms-Journal Nr. 34 finden Sie auf dem edoc-Server der Humboldt-Universität zu Berlin unter http://edoc.hu-berlin.de/cmsj/34
Copyright
Dieser Artikel ist ein Open Access Artikel und steht unter der Creative Commons Lizenz BY (siehe...).

Shibboleth SSO


Petra Berg
petra.berg@cms.hu-berlin.de

Keywords

SSO, Single Sign On, Shibboleth, Föderation

Abstract

Webbasierte Dienste innerhalb der Universität sowie in deren Umfeld gewinnen immer mehr an Bedeutung. Im Zuge dessen wird es immer wichtiger, webbasierte Systeme zur Authentifizierung und Autorisierung zentral bereitzustellen. Shibboleth ist ein solches System. Es verwirklicht Single Sign On (SSO) zur Authentifizierung und stellt unter Berücksichtigung datenschutzrechtlicher Aspekte Informationen zum Nutzer (Attribute) zur Autorisierung bereit. Zusätzlich ermöglicht Shibboleth das Bilden von Vertrauensgruppen, den sogenannten Föderationen, die eine gegenseitige Nutzung von Diensten erlauben. Nachfolgender Beitrag beschreibt die Funktion von Shibboleth aus Sicht des Nutzers sowie die technische Umsetzung aus Sicht des Administrators


Shibboleth – Funktion

image

Viele webbasierte Dienste der Humboldt-Universität sind auf eine Authentifizierung ihrer Nutzer und häufig auch auf deren Autorisierung angewiesen. Momentan implementieren die meisten Dienste eigene Anmeldefunktionen, was zur Folge hat, dass der Nutzer täglich mit mehreren verschiedenen Web-Oberflächen zur Anmeldung konfrontiert wird.

Eine für den Nutzer leichter handhabbare Lösung bietet das Shibboleth-System, welches ihm 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-System. Als Sitzung wird dabei der Zeitraum zwischen dem Öffnen des Browsers und dem Schließen der letzten offenen Instanz des Browsers bezeichnet. Ein Logout in der Web-Anwendung beendet die Shibboleth-Sitzung ebenfalls, aber ohne Schließen des Browsers.

Zusätzlich zur Authentifizierung des Nutzers kann das Shibboleth-System sogenannte Attribute für die Autorisierung des Nutzers an den Dienst liefern. Attribute sind Informationen zum Nutzer, die vom Identitätsmanagement bereitgestellt werden. 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 Szenarien für den Zugriff auf webbasierte Dienste innerhalb einer laufenden Sitzung:

Inhaltsverzeichnis

Shibboleth – Funktion ...

Erster Zugriff ...

Jeder weitere Zugriff...

Shibboleth – Föderationen...

Technische Umsetzung ...

Fazit ...

Literatur ...


Erster Zugriff

Der Nutzer öffnet seinen Browser und wählt die Adresse des gewünschten Dienstes (siehe Abbildung 1: 1Starte Dienst). Auf dem Server des Dienstanbieters, Service-Provider (SP) genannt, leitet das Shibboleth-SP-Modul den Browser an den zentralen Shibboleth-Server, den sogenannten Identity-Provider (IdP) weiter (Abbildung 1: 6 Umleitung), denn dieser kennt den Nutzer. Der IdP präsentiert dem Nutzer im Browser die Login-Seite, in die er seinen Nutzernamen und das Passwort eingeben muss (Abbildung 1: 7Login? und 8 Login.).

Mit Nutzernamen und Passwort schaut der IdP in seine definierte Menge von Identitätsdaten (bereitgestellt von einem Identitätsmanagement), ob ein Nutzer mit dem angegebenen Account und Passwort existiert. Ist er vorhanden, ist der Nutzer authentifiziert. Kommt er hingegen in keinem Eintrag vor, 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 deren Kennung 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, ermittelt der IdP, welche weiteren Informationen zum Nutzer vom aktuellen Dienst benötigt werden. Das sind die sogenannten Attribute. Wieder schaut der IdP in seine definierte Menge 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).

Das Shibboleth-SP-Modul packt die Nachricht aus und übergibt dem eigentlichen Dienst die Attribute. Anschließend überträgt das Shibboleth-SP-Modul dem eigentlichen Dienst die Kontrolle (Abbildung 1: 12 Dienst!). Der Dienst kann jetzt mit Hilfe der Attribute entscheiden, welche Funktionen dem Nutzer zur Verfügung stehen.

Inhaltsverzeichnis

Shibboleth – Funktion ...

Erster Zugriff ...

Jeder weitere Zugriff...

Shibboleth – Föderationen...

Technische Umsetzung ...

Fazit ...

Literatur ...


Jeder weitere Zugriff

Der Nutzer wählt im gleichen Browser die Adresse eines weiteren Dienstes. Das Shibboleth-SP-Modul leitet auch in diesem Fall wieder zum IdP weiter. Dieser liest das Cookie und erkennt die Shibboleth-Sitzung. Anschließend überprüft er, ob diese immer noch gültig ist. Je nach Konfiguration besitzt eine Shibboleth-Sitzung eine Gültigkeit von einer halben Stunde bis zu 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 7und 8 in Abbildung 1 entfallen in diesem Fall.

Alle weiteren Vorgänge sind identisch zu den beim ersten Zugriff ablaufenden Vorgängen. Auch hier muss der Nutzer wieder der Übertragung der Attribute zustimmen, wobei die Zustimmung mit großer Wahrscheinlichkeit aus vorangegangenen Sitzungen schon vorliegt (da einmalig je Dienst und Nutzer) und damit die Wege 9und 10 in Abbildung 1ebenfalls entfallen. Danach geht die Nachricht mit den Attributen wieder an das Shibboleth-SP-Modul zurück, das sie auspackt und dem aktuellen Dienst übergibt.

In diesem Fall laufen alle diese Prozesse im Hintergrund ab, ohne dass der Nutzer die Umleitungen bemerkt, da er über den Browser gleich die Seite des Dienstes präsentiert bekommt.

Inhaltsverzeichnis

Shibboleth – Funktion ...

Erster Zugriff ...

Jeder weitere Zugriff...

Shibboleth – Föderationen...

Technische Umsetzung ...

Fazit ...

Literatur ...


Shibboleth – Föderationen

Eine Shibboleth-Föderation ist eine Organisation mehrerer Einrichtungen (z. B. Universitäten, Hochschulen, Verlage), die bestimmte Kriterien zur Sicherheit und Genauigkeit der Daten und damit der Vertraulichkeit erfüllen. Durch eine Föderation ist es möglich, Web-Dienste Zugehörigen anderer Institutionen innerhalb der Föderation zugänglich zu machen und selbst Web-Dienste anderer Einrichtungen zu nutzen.

Möchte ein Nutzer auf Web-Dienste fremder Einrichtungen innerhalb der Föderation zugreifen, ist 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 und die damit seine Identität verwaltet.

image

Abb. 1: Shibboleth-Anmeldung aus Nutzersicht

Für den ersten Zugriff innerhalb einer laufenden Sitzung geht also die erste Umleitung vom SP-Modul zum sogenannten Discovery Service (DS) (Abbildung 1: 2Umleitung). 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 3und 4in der Abbildung 1weg. Liegt dem DS die Heimateinrichtung vor, schickt er diese an das SP-Modul zurück (Abbildung 1: 5 Umleitung).

Die weiteren Schritte sind identisch zum Verlauf der Anmeldung in den anfänglich beschriebenen Szenarien (siehe oben).

Inhaltsverzeichnis

Shibboleth – Funktion ...

Erster Zugriff ...

Jeder weitere Zugriff...

Shibboleth – Föderationen...

Technische Umsetzung ...

Fazit ...

Literatur ...


Technische Umsetzung

Für die Funktion von Shibboleth spielen sogenannte Metadaten eine wesentliche Rolle. Die Metadaten eines an Shibboleth teilnehmenden Dienstes sind zugleich Ausweis und Eintrittskarte und müssen daher besonders geschützt werden. Sie enthalten wichtige Informationen über unterstützte Services, deren Adressierung sowie die Zertifikate, die zum Verschlüsseln und Signieren verwendet werden.

Die Metadaten werden aus der Konfiguration der Shibboleth-Komponente mit Hilfe eines enthaltenen Generators oder manuell erzeugt. Diese Metadaten müssen allen Identity-Providern der Föderation bekannt sein. Da die Metadaten hierarchisch organisiert sind, können sie zentral gesammelt und bereitgestellt werden.

Jeder Shibboleth-Teilnehmer, sowohl Service-Provider (Dienst) als auch Identity-Provider, kann beliebig viele Quellen für Metadaten konfigurieren und so Mitglied in mehreren Föderationen sein. Wichtig ist, dass die Metadaten immer von einer verlässlichen Quelle stammen und dies durch eine gültige digitale Signatur bezeugen. Zusätzlich sollten Metadaten aus Sicherheitsgründen eine begrenzte Gültigkeit haben, die jeweils vor Ablauf erneuert wird.

Damit die Nutzer das Shibboleth-System optimal nutzen können, müssen möglichst alle Web-Dienste mit Authentifizierung an der Humboldt-Universität auf Shibboleth umgestellt werden.

Für die Umstellung von Web-Diensten der HU sind im Allgemeinen folgende Schritte vom Dienstanbieter nötig:

  1. Vorlage eines vom Datenschutzbeauftragten bestätigten Sicherheitskonzeptes für den Web-Dienst
  2. Mitbestimmungsantrag an die zuständigen Personalräte, mit Vorlage des bestätigten Sicherheitskonzeptes zur Kenntnisnahme
  3. Installation des Shibboleth-SP-Moduls auf dem Web-Server
  4. Konfiguration des Shibboleth-SP-Moduls entsprechend der ShibbolethSP-Konfigurationsanleitung
  5. Erstellen der Metadaten zum SP mit bereitgestellter Web-Anwendung
  6. Zentrale Freischaltung der SP-Metadaten und damit des Dienstes

Schritt 1 ist dabei als selbstverständlich zu betrachten, da ein solches Sicherheitskonzept für jeden Web-Dienst an der Humboldt-Universität vorliegen muss.

Schritt 2 ermöglicht den zuständigen Personalräten, von ihrem Recht auf Mitbestimmung Gebrauch zu machen.

Schritt 3 umfasst das Laden und Installieren des Shibboleth-SP-Moduls, welches als Debian Package unter den Bestimmungen der Apache Licence 2.0 verfügbar ist.

Für Schritt 4 steht eine ausführliche Anleitung zur Verfügung, die wiederum Schritt für Schritt die nötigen Konfigurationen für das Shibboleth-SP-Modul enthält. Die Konfiguration wird durch im Installationspaket enthaltene Vorlagen erleichtert, die nur geeignet angepasst werden müssen.

Schritt 5 ist der wichtigste Schritt zur Nutzung von Shibboleth aus Sicht des Web-Dienst-Anbieters. Über eine speziell für diesen Zweck implementierte Web-Anwendung werden die Metadaten des betreffenden SPs aufgenommen bzw. erzeugt. Anschließend werden die resultierenden Metadaten auf Korrektheit und Vertrauenswürdigkeit geprüft. Sind die Daten korrekt und vertrauenswürdig, können sie als Metadaten exportiert werden.

In Schritt 6 werden die SP-Metadaten zentral in die Menge der Metadaten aller Teilnehmer eingetragen. Damit ist der betreffende Dienst freigeschaltet und kann am Shibboleth-System teilnehmen.

Inhaltsverzeichnis

Shibboleth – Funktion ...

Erster Zugriff ...

Jeder weitere Zugriff...

Shibboleth – Föderationen...

Technische Umsetzung ...

Fazit ...

Literatur ...


Fazit

Der Einsatz von Shibboleth birgt wesentliche Vorteile in Bezug auf die Nutzung von Web-Diensten. Punkt eins ist die Vereinfachung von Authentifizierung und Autorisierung für Web-Dienste aus Sicht des Nutzers. Punkt zwei ist die Möglichkeit, innerhalb von Föderationen Web-Dienste einem größeren Nutzer-kreis zur Verfügung zu stellen und so eine umfangreiche Kooperation der Einrichtungen untereinander zu schaffen.

Literatur

[1] Internet2: Shibboleth. http://shibboleth.internet2.edu/
[2] DFN-AAI – Authentifikations- und Autorisierungs-Infrastruktur. https://www.aai.dfn.de/