Technische Übersicht zu Shibboleth 2. Shibboleth-Workshop, Freiburg, 23.03.2006 Franck Borel, UB...

Technische Übersicht zu Shibboleth

2. Shibboleth-Workshop, Freiburg, 23.03.2006

Franck Borel, UB [email protected]

Franck Borel, UB Freiburg 2

Übersicht

• Wissen – Verstehen – Anwenden– Eigenschaften von Shibboleth– Wie funktioniert Shibboleth?– Shibboleth in der Praxis– Shibboleth in der Zukunft


Eigenschaften von Shibboleth

• Gesicherter Zugang zu webbasierten Diensten• Gewährleistet anonymen Zugang zu Informationen und

Ressourcen, wobei der Zutritt beliebigen Gruppen/Personen zugewiesen werden kann (z.B. Universität, Fakultät, Prof. Ziegenbart)

• Single Sign-On• Freie Wahl des Authentifizierungssystems (erwartet

Umgebungsvariable REMOTE_USER)• Autorisierung erfolgt über Attribute• Nachrichten werden mit Hilfe von SOAP und SAML-

Anfragen/Antworten ausgetauscht• Open-Source (Apache 2.0 Lizenz)• Setzt auf bewährte Software und Standards auf und unterstützt

die wichtigsten Betriebssysteme


Föderation

Wie funktioniert Shibboleth?

Heimat-einrichtung mit

Identity-Provider

Heimat-einrichtung mit

Identity-Provider

Anbieter mitService-Provider

Anbieter mitService-Provider

WAYFWAYF

AuthentifizierungAutorisierung

AuthentifizierungAutorisierung

Ressourcen-verwaltung, Zugangs-

berechtigung

Ressourcen-verwaltung, Zugangs-

berechtigung

Ordnet einen Benutzer seiner

Heimateinrichtung zu

Ordnet einen Benutzer seiner

Heimateinrichtung zu

Vertragspartner, Operator, rechtliche Belange

Vertragspartner, Operator, rechtliche Belange



• Wodurch wird die Kommunikation zwischen Service-Provider und Identity-Provider ermöglicht? – HTTP / HTTPS (Port 80, 443, 8443)– Browser/Post (sichtbar für den Benutzer)– Browser/Artifact (nicht sichtbar für den Benutzer)– Umgebungsvariablen– SAML-Nachrichten– Metadaten



• SAML-Nachricht: Dient der Übertragung von Anfragen und Antworten

HTTP/HTTPS

SOAP Nachricht

SOAP Kopf

SOAP Inhalt

SAML Anfrage/Antwort



• SAML-Nachrichten– Eigenschaften:

• Können digital signiert werden

• Werden in fünf verschiedenen Varianten verwendet:a. Bestätigung einer erfolgreichen Authentifizierung

b. Attribute

c. Fehlerrückmeldung

d. Autorisierungsnachricht anhand derer der Service Provider entscheiden kann, ob ein Benutzer auf eine Ressource zugreifen darf oder nicht

e. Zusammengesetzter Typ aus a und b (Browser/Artifact)



• Metadaten– Ermöglichen die Kommunikation zwischen Identity-

Provider und Service-Provider– In den Metadaten sind Identity-Provider und Service-

Provider aufgeführt, die an den Austausch von Nachrichten beteiligt sind

– Nur in dem Metadaten aufgeführte Zertifikate werden akzeptiert



• Metadaten: Aufbau

<EntitiesDescriptor>

<Extensions> <ds:KeyInfo /> </Extensions>

<EntityDescriptor> <IDPSSODescriptor /> </EntityDescriptor> <EntityDescriptor> <SPSSODescriptor /> </EntityDescriptor>

</EntitiesDescriptor>

RahmenRahmen

Stamm-Zertifkate

Stamm-Zertifkate

Identity Provider und

Service Provider

Identity Provider und

Service Provider



Benutzerin

Service-Provider

(4)(5) Benutzerin berechtigt?

(6)

(7)

(8) verweigertnein

(3)

(9)gestattet Zugriffja

Identity-ProviderIdentity-Provider

WAYFWAYF

Benutzerin bekannt?

ja

nein(2)

(1)



AuthentifizierungAttribute

Authority (AA)Attribute

Authority (AA)

SSO DienstSSO

Dienst

Artifact Resolution

Service

Artifact Resolution

Service

Assertion Consumer

Service

Assertion Consumer

Service

Target ResourceTarget

Resource

Access

Contro

l

Access

Contro

l

Identity Provider

(4) 302

(3) GET

(8) 302

(5) GET

(10) 200(9) GET(2) 302(1) GET

(6) POST

(7) 200

Szenario: Erstkontakt ohne WAYF mit Browser/Artifact

Service Provider

BenutzerBenutzer



• Sicherheitsmechanismen– SSL/TSL: Man-in-the-Middle, Message Modification,

Eavesdropping– XMLsig: Message Modification– Gültigkeitsdauer von Sitzungen, Bestätigungen,

Attributen (engl. Lifetime, TTL): Replay, DOS– Metadaten: DOS, Message Modification– Es werden keine personenbezogenen Daten übermittelt

sondern Stellvertreter (engl. Handler): Eavesdropping


Shibboleth in der Praxis

• Unterstützte Betriebssysteme:– Linux– Solaris– Windows– Mac OS-X



• Notwendige Software (Bsp. Linux):– Identity Provider:

• Tomcat • Apache mit mod_ssl (für HTTPS) und mod_jk

(Verbindung zum Tomcat)• JDK (für Tomcat und Identity-Provider)• Ant (Software entpacken)• OpenSAML (transportieren, erstellen und parsen der

SAML-Nachrichten)• OpenSSL (für Server-Zertifikate) • NTP (Zeitstempel: Wie lange ist die SAML-Nachricht

gültig)



• Notwendige Software (Bsp. Linux): – Service Provider:

• Apache + mod_ssl (für HTTPS)

• OpenSSL (für Server-Zertifikate)

• NTP (Zeitstempel: Wie lange ist die SAML-Nachricht gültig?)

• Libcurl

• OpenSAML (transportieren, erstellen und parsen der SAML-Nachrichten)



• Optionale Software (Auszug):– WAYF (Internet2): Lokalisierungsdienst– Rechteserver (Uni-Regensburg): Attributübersetzung für

Service-Provider– Arpedit (Internet2): ARP-Editor für Identity Provider– Mod_auth_location (Internet2): Anonymer Zugang von

ausgewählten Browsern und Service Providern– ShARPE (MAMS): Administrationswerkzeug zum

Konfigurieren von ARP-Dateien– Autograph (MAMS): Benutzerwerkzeug zum Konfigurieren

von ARP-Dateien– Resource-Registry (SWITCH): Zentraler Datenspeicher, in

denen alle Informationen zu den Service Providern und Identity Providern zusammengetragen sind



• Erst-Installation: Wie geht man vor?– Dokumentationen zu Shibboleth – Installationsanleitung besorgen– Installation der Server und der Shibboleth-Software– Test-Konfiguration mit Hilfe der

AAR Demo-Umgebung– Feinabstimmung der Konfiguration (z.B. Session

Timeout, AAP, Logging)– Optionale Software einspielen und testen



• Potentielle Hürden:– Identity Provider:

• Standard Authentifizierung (Tomcat Valve) reicht nicht immer aus und muss daher angepasst werden, was wiederum tief greifende Kenntnisse über Tomcat verlangt

• Zertifikate• Shibboleth-Dokumentation• kein Single Log-Out (der Benutzer muss den Browser schliessen, um

alle Sitzungen zu beenden; für die Version 2.1 ist ein Single Log-Out geplant)

– Service Provider:• Zertifikate• Shibboleth-Dokumentation

– WAYF:• Keine Dokumentation vorhanden!



• Ein paar Beispiele zu Diensten, die shibboleth-fähig gemacht worden sind:– ReDI (UB Freiburg): Testphase

– Wiki (Ohio University): Produktionsphase

– Virtuelle Lernumgebung (Bodington.org): Produktionsphase

– Quicktime Streaming Server (Darwin Streaming Server): Produktionsphase

– Datenbank (EBSCO Publishing): Produktionsphase

– Napster: Produktionsphase

– E-Learning (OLAT Schweiz): Produktionsphase


Shibboleth in der Zukunft

• Für Shibboleth 2.x sind unter anderen folgende Erweiterungen geplant:– Anpassen an den SAML 2.0 Standard (z.B. Single Log-Out,

Authentifizierung wird stärker in den Identity-Provider eingebunden als bisher, Service-Provider bekommt weitere Konfigurationseinstellungen)

– ShARPE und Autograph als fester Bestandteil– Service Provider auch als Java-Servlet (2.3+)– der zentrale WAYF-Dienst fällt weg– es wird einen Discovery Service geben, der beim Service-

Provider installiert ist und auch mit mehreren Föderationszugehörigkeiten zurecht kommt

– Bessere Dokumentation


Ich danke Ihnen für Ihre Aufmerksamkeit!

Fragen?

Technische Übersicht zu Shibboleth 2. Shibboleth-Workshop, Freiburg, 23.03.2006 Franck Borel, UB...

Documents

Transcript of Technische Übersicht zu Shibboleth 2. Shibboleth-Workshop, Freiburg, 23.03.2006 Franck Borel, UB...