Shibboleth - Single Sign On (SSO) - Dokumentation

Eine neue Schnittstelle zur Anbindung an das IDM

  1. Einführung
    1. Was ist Shibboleth?
    2. Wofür wird es genutzt?
  2. Aufbau + Funktion
    1. Welche Bestandteile gibt es?
    2. Wie funktioniert es?
  3. Warum Shibboleth?
    1. Alternativen
    2. Welche Vorteile bringt Shibboleth?
  4. Anbindung / Umsetzung
    1. Voraussetzungen
    2. Beantragung
    3. Installation
    4. Konfiguration
    5. Sonstiges
    6. FAQ / Common Errors
  5. Entwicklung an der TU
    1. Vergangenheit
    2. Aktueller Stand / Zukunft
  6. DFN-AAI Förderation
  7. Links / Dokumentation

1. Einführung

a) Was ist Shibboleth?

Seitenanfang

b) Wofür wird es genutzt?

Basierend auf der Security Assertion Markup Language (SAML)

Seitenanfang

2. Aufbau + Funktion

a) Welche Bestandteile gibt es?

Seitenanfang

b) Wie funktioniert es?

Je nach Konfiguration des SP kann der Ablauf vom gezeigten Verhalten abweichen.
Dies hängt davon ab, ob der Dienst z.B. für eine einzelne Einrichtung bereit steht oder mehreren zeitgleich angeboten wird.

Bei nur einer Zieleinrichtung entfallen die Schritte 2-4!

WAYF
browser-flow
IdP SP
  1. Nutzer wählt die gewünschte URL (Resource beim SP) in seinem Browser aus
  2. SP prüft ob Nutzer bereits eingeloggt
    • bei Erfolg liefert der SP die angeforderte Seite aus (der weitere Ablauf wird gestoppt)
    • bei Miss-Erfolg leitet der SP den Nutzer an einen Discovery-Service weiter (via Redirect)
  3. Nutzer wählt aus einer Liste, zu welcher Organisation er gehört
  4. der Discovery-Service leitet den Nutzer (via Redirect) an den ursprünglichen SP zurück
  5. der SP stellt nun eine Authentifizierungs-Anfrage an den ausgewählten IdP
    • ist der Nutzer bereits am IdP eingeloggt so wird er wieder an den SP zurückgeleitet (keine weiteren Schritte am IdP)
    • existiert keine gültige Session für den Nutzer fragt der IdP den Nutzer nach seinen Zugangsdaten (in Form einer Login-Seite)
  6. Nutzer gibt seine Zugangsdaten am IdP ein
  7. bei Erfolg wird der Nutzer vom IdP wieder zurück an den SP geschickt
    • der IdP teilt dem SP unter anderem mit, dass sich dieser erfolgreich Authentifiziert hat
    • darüber hinaus werden wenn vom Nutzer aktzeptiert weitere Informationen (Attribute) an den SP weitergegeben
    • der SP wertet die Attribute aus, um eventuelle Zugriffsberechtigungen zu prüfen
    • darf der Nutzer auf die angeforderte Seite zugreifen, so wird ihm diese ausgeliefert
Seitenanfang

3. Warum Shibboleth?

a) Alternativen

Seitenanfang

b) Welche Vorteile bringt Shibboleth?

Einziger Nachteil aus Sicht des Anbieters: kein direkter Zugriff auf Nutzerdaten

Seitenanfang

4. Anbindung / Umsetzung

a) Voraussetzungen

Linux Shibboleth kann auf den meisten 32- und 64-Bit-Linux-Versionen gebaut werden. Offiziell unterstützt werden folgende Distributionen:

Es werden RPM-Pakete verwendet, die auf den offiziellen Spiegelservern des Projektes verfügbar sind.

Windows Es werden Windows Server 2008 und höher unterstützt. Es werden Installer für 32-Bit und 64-Bit Systeme angeboten.

macOS Wird nicht offiziell unterstützt, aber es gibt einen macport für alle Abhängigkeiten und den SP selbst. Es wird auf freiwilliger Basis gepflegt.

Seitenanfang

b) Beantragung

Das Shibboleth-Antragsformular, welches notwendig ist damit Sie einen Ihrer Dienste "shibbolisieren" und an den Identityprovider der TU Dresden anbinden können, finden Sie im Dienstekatalog des ZIH unter dem Punkt Authentifizierungs­dienste.

Möchten Sie die technische Anbindung zunächst testen um mögliche Probleme zu erkennen oder einfach nur Erfahrungen im Umgang mit Shibboleth sammeln, so stellt die TU Dresden neben einem produktiven Shibboleth-System auch eine Test-Instanz zur Verfügung.
Eine Anbindung an die Test-Umgebung ist jeder Zeit möglich und ohne große Beantragungs-Prozesse verbunden. Hier genügt eine formlose E-Mail an den Servicedesk.
Bitte beachten Sie jedoch, dass die vom Test-System bereit gestellten Nutzer-Informationen lediglich Dummy-Werte sind und keine Echtdaten enthalten.
Dafür besteht hier die Möglichkeit beliebige Accounts mit Wunschwerten zu erhalten um z.B. interne Berechtigungen Ihrer Anwendungen zu prüfen.

Bevor Sie den Antrag ausgefüllt und digital unterschrieben an den Service Desk senden, lesen Sie sich bitte die folgenden Schritte zur Einrichtung Ihres Shibboleth-Serviceproviders durch.
Welche Attribute Sie beantragen und aus dem IDM-System geliefert bekommen können, sowie eine nähere Beschreibung der Attribut-Definitionen entnehmen Sie diesen PDF-Dokumenten:

Zum Anbinden werden die Metadaten des SPs benötigt. Bitte als Anhang dem Ticket beifügen.
Genauere Informationen was die Metadaten eigentlich sind, was diese enthalten und wie Sie diese erhalten, entnehmen Sie dem Punkt Metadaten dieser Anleitung.

Wenn Ihr Dienst nicht nur TU intern, sondern auch Angehörigen anderer Heimateinrichtungen zur Verfügung stehen soll, vermerken Sie dies im Antrag.
Wir kümmern uns um die Aufnahme in die DFN-AAI oder auch die eduGAIN Föderation.

Seitenanfang

c) Installation

Bitte befolgen Sie die Installations-Anweisungen des Shibboleth-Consortiums für

Nachdem der SP erfolgreich auf Ihre System installiert wurde, sind folgende Verzeichnisse von besonderem Interesse:

Konfigurationsverzeichnis von Shibboleth. Die wichtigste Konfigurationsdatei ist shibboleth2.xml.
Linux /etc/shibboleth
Windows C:\opt\shibboleth-sp\etc\shibboleth

Log-Verzeichnis, in das die Logs geschrieben werden.
Im shibd.log finden Sie Einträge zu SAML, Meatadaten oder Sicherheitsproblemmen.
Im transaction.log sind die eigentlichen Transaktionen, die am SP eingehen.
Linux /var/log/shibboleth
Windows C:\opt\shibboleth-sp\var\log\shibboleth

Laufzeitverzeichnis, in dem die Prozess-ID und Socket-Dateien gespeichert werden.
Linux /run/shibboleth
Windows C:\opt\shibboleth-sp\var\run\shibboleth

Cache-Verzeichnis, in dem Metadaten-Backups und CRL-Dateien gecached werden.
Linux /var/cache/shibboleth
Windows C:\opt\shibboleth-sp\var\cache\shibboleth

Seitenanfang

d) Konfiguration

Die Hälfte von Shibboleth läuft innerhalb des Webservers.
Für Apache ist diese Hälfte in einem Modul namens mod_shib_22.so oder mod_shib_24.so implementiert, je nach Apache-Version.

Apache anpassen /etc/apache2/vhosts.d/ihr-sp.conf

Laden des Shibboleth-Modul 

LoadModule mod_shib /usr/lib64/shibboleth/mod_shib_24.so

Weiterleitung von "http" zu "https"

<VirtualHost *:80>
	RedirectMatch permanent ^/(.*)$ https://ihr-sp.tu-dresden.de/$1
</VirtualHost>

Anfragen werden 1:1 an HTTPS weitergegeben.
Alle eingegebenen URLs bleiben erhalten.

Einstellungen für "https" (Ciphersuiten und andere Sicherheitseinstellungen)

SSLStaplingCache shmcb:/tmp/stapling_cache(102400)

<VirtualHost *:443>
	ServerName		ihr-sp.tu-dresden.de

	Header edit Set-Cookie "(?i)^((?:(?!;\s?HttpOnly).)+)$" "$1; HttpOnly"
	Header edit Set-Cookie "(?i)^((?:(?!;\s?Secure).)+)$" "$1; Secure"
	Header add Strict-Transport-Security "max-age=15768000"

	SSLEngine                         on
	SSLCertificateFile                /etc/ssl/localcerts/ihr-sp.crt.pem
	SSLCertificateKeyFile             /etc/ssl/private/ihr-sp.key.pem

	SSLProtocol             		  all -SSLv3 -TLSv1 -TLSv1.1
	SSLCipherSuite          		  ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305
	SSLHonorCipherOrder               On

	SSLUseStapling                    on
	SSLStaplingReturnResponderErrors  off
	SSLCompression                    off
	SSLSessionTickets                 off

Freischalten des Shibboleth-Modul

	<Location /Shibboleth.sso>
		AuthType None
		Require all granted
	</Location>

Ressource durch Shibboleth schützen

	<Location /secure>
		AuthType shibboleth
		ShibRequestSetting requireSession 1
		require shib-session
	</Location>
</VirtualHost>

Hiermit wird erreicht, dass nur authentifizierte Nutzende Zugriff zu der geschützten Ressource https://ihr-sp.tu-dresden.de/secure erhalten.
Weitere Beispiele zur Autorisierungskonfiguration auf Webserverebene finden im Shibboleth Wiki unter AuthConfig Options.

Eempfohlene Webserver Einstellungen /etc/apache2/httpd.conf

ServerSignature     off
UseCanonicalName    off
ServerTokens        ProductOnly
ExtendedStatus      off
TraceEnable         off

Apache neustarten

# Konfiguration auf Korrektheit prüfen
:~ httpd -t
Syntax OK

# Apache neu starten
:~ systemctl restart apache2.service

Seitenanfang
Seitenanfang

e) Sonstiges

Seitenanfang
Seitenanfang
Seitenanfang
Seitenanfang
Seitenanfang
Seitenanfang
Seitenanfang

f) FAQ / Common Errors

Weitere bekannte Fehler finden Sie direkt beim Hersteller beschrieben.
Seitenanfang

5. Entwicklung an der TU

a) Vergangenheit

Seitenanfang

b) Aktueller Stand / Zukunft

Seitenanfang

6. DFN-AAI Förderation

Seitenanfang

7. Links / Dokumentation

Seitenanfang
Es gilt das Impressum der TU-Dresden mit folgenden Abweichungen:
Konzeption, Realisierung, Betreiber:
Technische Universität Dresden
Zentrum für Informationsdienste und Hochleistungsrechnen
01062 Dresden
Für Rückfragen kontaktieren Sie bitte den Service Desk
Tel.: +49 351 463-40000
Fax: +49 351 463-42328
E-Mail: Service Desk