ServiceProvider mit Shibboleth einrichten und betreiben

Grundlagen

Möchten Sie Anwendungen mit Hilfe von Shibboleth schützen, erhalten Sie hier Hinweise zur Konfiguration und Betrieb.

Erläuterungen zur Funktionsweise des SSO (Sing Sign-On) mit Shibboleth-IDP und Shibboleth-SP:

Vorgehen

Vorbereitung

Webbasierte Anwendungen, die eine einfache Anmeldung mit Boardmitteln des Apache Webservers oder IIS realisieren, lassen sich in der Regel problemlos auf die Anmeldung mit Shibboleth umstellen. Auch JAVA-Anwendungen können "shibbolisiert" werden. Neben der reinen Prüfung der Zugangsdaten kann Shibboleth zusätzlich zur Authentifizierung Attribute wie z.B. Vor- und Nachnamen, E-Mail-Adresse, Art der Zugehörigkeit zur Universität etc. übertragen. Damit ist es möglich, den Zugriff schon am Webserver für bestimmte Nutzergruppen einzuschränken.

Möchten Sie auch lokale Nutzerdatenbanken bei Anmeldung aktualisieren, muss die Anwendung Shibboleth (SAML) unterstützten. Standardmäßig stellt Shibboleth im REMOTE_USER einen eindeutigen Identifier zur Verfügung. Kann der REMOTE_USER durch die Anwendung ausgewertet werden, vereinfacht dies bereits einiges.

Beachten Sie bitte, dass in der Regel auch ohne offensichtlichen Personenbezug bereits eine Verarbeitung im Sinne der DSGVO stattfindet und eine Anbindung an Shibboleth erst nach Vorlage der Verarbeitungstätigkeit nach Art. 30 Abs. 1 DSGVO möglich ist.

Nehmen Sie für eine erste Beratung Kontakt mit der Abteilung Serverdienste auf. Konkrete Unterstützung bei der Anpassung der Anwendung und auch für den laufenden Betrieb kann leider nicht geleistet werden!

Installation und Konfiguration

Beantragen Sie ein Serverzertifikat und wählen als Zertifikatsprofil die Option Shibboleth IdP SP aus. Nutzen Sie dieses Zertifikat für die Kommunikation des Webservers. Für die Signierung und Verschlüsselung des Shibboleth-SPs kommt die interne CA https://pki.pca.dfn.de/uni-bamberg-internal-ca/pub zum Einsatz. Hier beantagen Sie über einen weiteren Request, wir empfehlen hier auch einen zusätzlichen private key neben dem zusätzlichem Zertifikat, ebenfalls ein Serverzertifikat und wählen als Zertifikatsprofil die Option Shibboleth IdP SP aus und senden den Zertifikasantrag als signierte persönliche E-Mail an aai.pki-service(at)uni-bamberg.de (Ablauf sonst analog Serverzertifikat). Stellen Sie das Serverzertifikat der internen CA ohne privaten Schlüssel der Abteilung Serverdienste zur Aufnahme in die Metadaten zur Verfügung.

Shibboleth eignet sich zur Installation unter Linux für den Apache-Webserver 2.4 oder unter Windows am IIS. Vorbereitend laden Sie sich die Zertifikatskette sowie das Signatur-Zertifikat der Metadaten für die spätere Verwendung herunter.

Folgen Sie der Installationsanleitung der schweizer Kollegen und verwenden keinesfalls die migelieferten Pakete der debian-basierten Distributionen, da diese nicht aktuell sind! Verwenden Sie unbedingt die speziell für die Universität Bamberg angepasste Beispielkonfigurationen für den Betrieb eines Serviceproviders shibboleth2.xml(14.8 KB) und für den Betrieb des Apache-Webservers httpd.conf(3.3 KB). Beim Betrieb im IIS ist es notwendig, das Rewrite-Modul zu installieren und dann die web.config im Ordner c:/inetpub/wwwroot(1.2 KB) anzupassen (die 3 Regeln müssen vor ggf. weiteren Regeln stehen, Achtung - Logfiles vom IIS können sich erheblich vergrößern!).

Konfigurationseinstellungen finden Sie auf folgenden Seiten:

Eine sehr gute Dokumentation für die Zugriffbeschränkungen findet sich unter https://www.switch.ch/aai/guides/sp/access-rules/. Neben des SingleSignOn gilt es auch das SingeLogOut zu beachten.

Betrieb: Certificate Rollover

Diese Anleitung betrifft nicht das Webserver-Zertifikat. Dieses kann unmittelbar nach Erstellung des neuen Serverzertifikats im Zertifikatsprofil mit der Option Shibboleth IdP SP getauscht werden.

Um den unterbrechungsfreien Betrieb des ServiceProviders sicherzustellen, ist es erforderlich, Zertifikate rechtzeitig, d.h. unmittelbar nach Eintreffen der Warnmeldung über den Ablauf des Zertifikats, zu erneuern und in den Metadaten bekannt zu machen. Während des Rollovers werden das alte und das neue Zertifikat verwendet. Dazu sind folgende Schritte notwendig:

  1. Erstellen Sie über die interne CA https://pki.pca.dfn.de/uni-bamberg-internal-ca/pub ein Serverzertifikat und wählen als Zertifikatsprofil die Option Shibboleth IdP SP aus und senden den Zertifikasantrag als signierte persönliche E-Mail an aai.pki-service(at)uni-bamberg.de (Ablauf sonst analog Serverzertifikat) . 
  2. Konfiguieren Sie das neue Zertifikat und den neuen privaten Schlüssel an zweiter Stelle shibboleth2.xml:
    <CredentialResolver type="Chaining">
                <CredentialResolver type="File" keyName="Active" key="/etc/ssl/private/old_key_spname_date.pem" certificate="/etc/ssl/certs/old_cert_spname_date.pem"/>
                <CredentialResolver type="File" keyName="Standby" key="/etc/ssl/private/new_key_spname_date.pem" certificate="/etc/ssl/certs/new_cert_spname_date.pem"/>
    </CredentialResolver>
    und starten Shibboleth neu
    (ggf. muss ein Eintrag wie <CredentialResolver type="File" key="/etc/ssl/private/old_key_spname_date.pem" certificate="/etc/ssl/certs/old_cert_spname_date.pem"> durch den obigen "Chaining"-Block ersetzt werden.)
  3. Stellen Sie das neue Zertifikat der internen CA ohne privaten Schlüssel der Abteilung Serverdienste zur Aufnahme in die Metadaten zur Verfügung.
  4. Sobald das neue Zertifikat in die Metadaten aufgenommen ist, bekommen Sie Mitteilung und warten mindestens 24 Stunden, bis Sie mit Schritt 5. fortfahren.
  5. Tauschen Sie die Zertifikate shibboleth2.xml
    <CredentialResolver type="Chaining">
                <CredentialResolver type="File" keyName="Active" key="/etc/ssl/private/new_key_spname_date.pem" certificate="/etc/ssl/certs/new_cert_spname_date.pem"/>
                <CredentialResolver type="File" keyName="Standby" key="/etc/ssl/private/old_key_spname_date.pem" certificate="/etc/ssl/certs/old_cert_spname_date.pem"/>
    </CredentialResolver>
    und starten Shibbleth neu.
  6. Melden Sie den erfolgten Zertifikatstausch der Abteilung Serverdienste.
  7. Sobald das alte Zertifikat aus den Metadaten entfernt ist, bekommen Sie Mitteilung und warten mindestens 24 Stunden, bis Sie mit Schritt 8. fortfahren.
  8. Entfernen Sie das alte Zertifikat shibboleth2.xml
    <CredentialResolver type="Chaining">  
                <CredentialResolver type="File" keyName="Active" key="/etc/ssl/private/new_key_spname_date.pem" certificate="/etc/ssl/certs/new_cert_spname_date.pem"/>
                <!--
               
    <CredentialResolver type="File" keyName="Standby" key="/etc/ssl/old_private/key_spname_date.pem" certificate="/etc/ssl/certs/old_cert_spname_date.pem"/>
                -->
    </CredentialResolver>
    und starten Shibboleth neu.
  9. Das Certificate Rollover ist beendet.