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 188bet亚洲体育备用_188体育平台-投注*官网 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.