Durch den Einsatz von Shibboleth soll es Benutzern verschiedenster netzwerkgestützter Dienstleistungen ermöglicht werden, diese organisationsübergreifend und durch einmaliges Anmelden nutzen zu können (Single-Sign-On System). Der Datenschutz soll dabei besondere Beachtung erhalten.

Wenn sich Organisationen wie etwa Hochschulen entschließen, gemeinsam Shibboleth zu benutzen, um damit ihren Benutzern Dienste organisationsübergreifend zur Verfügung zu stellen, entsteht eine Föderation. Shibboleth unterstützt Föderationen durch leicht erweiterbare Methoden des Managements und der Verteilung von Konfigurations- und Sicherheitsinformationen über viele Organisationen. Es wird auch ein breites Spektrum an möglichen Benutzerattributen bereitgestellt. Shibboleth unterscheidet dabei nach Nutzern und Dienstanbietern. Die Administration von Nutzeridentitäten und -attributen ist Aufgabe der jeweiligen „Heimatorganisation“, im Folgenden als Identity Provider bezeichnet. Im Universitätsumfeld tritt als Provider in der Regel die Universität auf, bei der der Nutzer immatrikuliert ist. Der Dienstanbieter wird im Weiteren Service Provider genannt.

Die Architektur von Shibboleth besteht aus mehreren Komponenten, die sowohl bei den Service Providern, als auch bei den Identity Providern angesiedelt sind. Vorab sollen diese kurz beschrieben werden, bevor dann ihre Interaktion im Detail dargestellt wird. Auf Seiten eines Identity Providers werden dabei die folgenden beiden Komponenten betrieben:

• Handle Service (HS): Der Handle Service ist für die lokale Authentifizierung des Nutzers zuständig. Dazu wird er an ein vorhandenes Authentifizierungssystem angebunden. Nach erfolgreicher Authentifizierung liefert er an den Service Provider ein Attribute Query Handle (AQH) zurück.

• Attribute Authority (AA): Die Attribute Authority nimmt Anfragen von Service Providern nach Attributen über Nutzer entgegen und beantwortet sie. Dabei werden nur solche Attribute weitergegeben, die aufgrund der für diesen Anbieter geltenden, ggf. nutzerspezifischen, Attribute Release Policy (ARP) übermittelt werden dürfen. Zur Ermittlung der Attribute bedient sich die AA dabei eines lokalen Verzeichnisses.

Auf Seiten des Service Providers kommen folgende drei Komponenten zum Einsatz:

• Shibboleth Indexical Reference Establisher (SHIRE): Aufgabe des SHIRE ist die Ermittlung eines AQH für den Nutzer über den zuständigen Handle Service, ggf. unter Mitwirkung des WAYF-Dienstes (siehe unten).

• Shibboleth Attribute Requester (SHAR): Der SHAR ermittelt über die zuständige Attribute Authority Attribute über Nutzer, überprüft und filtert diese gegebenenfalls anhand seiner Attribute Acceptance Policy (AAP) und leitet sie an den Resource Manager weiter.

• Resource Manager (RM): Der Resource Manager entscheidet anhand der ihm bekannten Informationen über den Nutzer über die Gewährung des Zugriffs auf angebotene Dienste und sonstige Ressourcen.

Daneben gibt es noch den bekannten Where Are You From (WAYF) Dienst, der die Ermittlung des für einen Nutzer zuständigen Identity Providers bzw. konkret des zuständigen Handle Service übernimmt. Üblicherweise wird dabei der WAYF-Dienst von einer zentralen Instanz innerhalb eines Verbundes aus Service und Identity Providern betrieben.

Ablaufszenario:

Nachfolgend wird nun anhand von vier Phasen beschrieben, wie ein typisches Szenario im Rahmen von Shibboleth abläuft.

Phase 1: Benutzeranfrage, Weiterleitung zum WAYF Dienst

Shibboleth Szenario, Phase 1

1. Der Nutzer ruft mittels seines Browsers eine Webseite (target URL – Uniform Resource Locator) bzw. Ressource) eines Dienstes eines Service Providers auf, die Daten über den Nutzer mittels Shibboleth ermitteln möchte. Der Aufruf gelangt zur weiteren Bearbeitung intern an den SHIRE.

2. Der SHIRE leitet den Browser des Nutzers mittels Redirect auf den WAYF Dienst um. Dabei wird die target URL aus Schritt 1 und zusätzlich eine sogenannte handle acceptance URL des SHIRE als Parameter übergeben.

3. Der WAYF Dienst fragt vom Nutzer den Namen seines Identity Providers ab. Daraus ermittelt der WAYF Dienst die URL des entsprechenden Handle Service des Identity Providers.

Phase 2: Auswahl des Identity Providers, Authentifizierung

Shibboleth Szenario, Phase 2

4. Der Browser des Nutzers wird jetzt über einen weiteren Redirect auf den ermittelten Handle Service umgeleitet, dabei werden target URL und handle acceptance URL aus Schritt 2 unverändert als Parameter übergeben.

5. + 6. Der Handle Service versucht den Nutzer mittels dessen Credentials (üblicherweise Benutzername und Passwort) zu authentifizieren.

Phase 3: Erzeugung und Versand des Handles

Shibboleth Szenario, Phase 3

7. Der Handle Service erzeugt ein Attribute Query Handle (AQH). Es handelt sich dabei um einen eindeutigen Wert, anhand dessen nur die zuständige Attribute Authority den konkreten Nutzer erkennen kann. Das AQH wird signiert und zusammen mit Angaben zur zuständigen Attribute Authority und der target URL in ein HTML-Formular mit der Methode „POST“ verpackt, als Ziel wird die handle acceptance URL gesetzt.

    

8. Der Browser des Nutzers erhält nun dieses HTML-Formular innerhalb eines gewöhnlichen HTML-Dokumentes als Antwort auf seine „Anfrage“ aus Schritt 4, was letztendlich zur Übermittlung dieser Daten an den SHIRE führt.

    

9. Der SHIRE prüft das erhaltene AQH und gibt dieses zusammen mit Angaben zur zuständigen Attribute Authority und anderen Informationen an den SHAR weiter.

Phase 4: Überprüfung des AQH, Attributaustausch und Autorisierung

Shibboleth Szenario, Phase 4

11. Der SHAR sendet das Handle an die Attribute Authority zurück und fragt nach Attributen über den Nutzer mittels einer Attribute Query Message unter Verwendung des vom SHIRE ermittelten und erhaltenen AQH.

     

12. Die Attribute Authority überprüft das Handle auf seine Gültigkeit, stellt also sicher, dass es seit seiner Erzeugung nicht verändert worden ist.

     

13. Der SHAR erhält die Attribute mittels einer Attribute Response Message von der Attribute Authority. Dabei wird die Attribute Release Policy des Nutzers bezüglich dieses Providers beachtet.

     

14. Der SHAR leitet die ermittelten Attribute dann an den Resource Manager weiter. Der Resource Manager prüft anhand der Attribute, ob der Nutzer zum Zugriff auf den gewünschten Dienst des Service Providers berechtigt ist, entsprechend wird die Nutzeranfrage bearbeitet bzw. zurückgewiesen.

Quellen:

• Federated Identity Management mit Shibboleth , Tom Vedder, Fachhochschule Bonn-Rhein-Sieg

• SWITCH - http://www.switch.ch/de/aai

• Shibboleth® - http://shibboleth.internet2.edu

---

Zu Favoriten hinzufügen