ServiceProvider mit Shibboleth einrichten und betreiben

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!

Beantragen Sie ein Serverzertifikat. Nutzen Sie dieses Zertifikat für die Kommunikation des Webservers. Für die Signierung und Verschlüsselung des Shibboleth-SPs ist ein selbstsigniertes Zertifikat ausreichend. Dies erzeugen Sie mit openssl:

openssl req -x509 -days 1170 -newkey rsa:4096 -out certaai_<DNS>-<YYYY-MM-DD>.pem -keyout tmp.pem
#Passwort entfernen
openssl rsa -in tmp.pem -out keyaai_<DNS>-<YYYY-MM-DD>.pem

Alternativ 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. Nachdem Sie das Zertifikat der internen CA erhalten haben, stellen Sie dieses ohne privaten Schlüssel der Abteilung Serverdienste zur Aufnahme in die Metadaten zur Verfügung. Weitere Informationen zur Beantragung finden Sie unter Shibboleth-Zertifikate.

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. Folgen Sie der Installationsanleitung der schweizer Kollegen und verwenden keinesfalls die migelieferten Pakete der debian-basierten Distributionen, da diese nicht aktuell sind!

Unter Ubuntu 20.04/22.04 werden aktuelle Pakete nicht bzw. nur zögerlich über die offiziellen Quellen bereit gestellt. Daher werden selbst compilierte Pakete für Ubuntu für den internen Gebrauch zur Verfügung gestellt. Vor Installation über einen bestehenden SP bitte unbedingt selbst die Konfiguruation sichern. Der SP wird unter /opt/shibboleth-sp installiert und im Normalfall die bestehende Konfiguration übernommen.

Downloads Ubuntu 22.04(3.3 MB) und 20.04(2.9 MB).

Verwenden Sie unbedingt die speziell für die Universität Bamberg angepasste Beispielkonfigurationen für den Betrieb eines Serviceproviders shibboleth2.xml(13.9 KB) und für den Betrieb des Apache-Webservers httpd.conf(3.4 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!).

Metadaten werden vom DFN-Verein signiert zur Verfügung gestellt. Die Prüfung erfolgt zentral. Dadurch kann die lokale Prüfung am SP entfallen und die Startzeit wird wesentlich reduziert. Die Konfiguration ist entsprechend in der shibboleth2.xml vorbereitet.

Konfigurationseinstellungen finden Sie auf folgenden Seiten:

• https://www.switch.ch/de/aai/guides/sp/configuration/
• https://doku.tid.dfn.de/de:shibsp
• https://wiki.shibboleth.net/confluence/display/SP3/Configuration

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.

Diese Anleitung betrifft nicht das Webserver-Zertifikat.

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 ein selstsigniertes Zertifikat mit einer Laufzeit von maximal 1170 Tagen

   openssl req -x509 -days 1170 -newkey rsa:4096 -out certaai_<DNS>-<YYYY-MM-DD>.pem -keyout tmp.pem
   #Passwort entfernen
   openssl rsa -in tmp.pem -out keyaai_<DNS>-<YYYY-MM-DD>.pem

   Alternativ ist auch folgender Weg möglich.
   
   Erstellen Sie über die interne CA https://pki.pca.dfn.de/uni-bamberg-internal-ca/pub ein Serverzertifikat, wählen als Zertifikatsprofil die Option Shibboleth IdP SP aus und senden den Zertifikatsantrag als signierte persönliche E-Mail an aai.pki-service(at)uni-bamberg.de. Weitere Informationen zur Beantragung finden Sie unter Shibboleth-Zertifikate.
2. Nachdem Sie das Zertifikat erhalten haben, konfiguieren Sie dieses 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.