Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp:prepare-http [2020/04/14 15:21] – Silke Meyer
+++ de:shibidp:prepare-http [2024/11/12 14:25] (aktuell) – [Apache-Module aktivieren] : Zugriff auf Gruppe ssl-cert Thorsten Michels
@@ Zeile 1: / Zeile 1: @@
-====== IdP-Vorarbeiten: HTTP-Server ======
+<- de:shibidp:prepare-zert|Vorarbeiten: Zertifikate ^ de:shibidp:uebersicht|Überblick: Tutorial zur IdP-Inbetriebnahme ^ de:shibidp:install|IdP-Installation ->
+====== IdP-Vorarbeiten: Webserver ======
 <callout color="#ff9900" title="Firewall">
-Die TCP-Ports 443 und 8443 müssen auf dem IdP für eingehende Zugriffe geöffnet sein!
+Die TCP-Ports 443 und 8443 müssen auf dem IdP für eingehende Zugriffe geöffnet sein! Die Verwendung des Backchannels auf Port 8443 wird im [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631506/SecurityAndNetworking#Back-Channel-Support|Shibboleth-Wiki]] erklärt.
 </callout>
@@ Zeile 9: / Zeile 11: @@
 ==== Installation ====
-=== Debian 10 ===
+=== Debian 12 ===
 <code bash>
@@ Zeile 15: / Zeile 17: @@
 </code>
-=== RHEL 6/CentOS 7 ===
+==== Apache-Module aktivieren ====
 <code bash>
-root@idp:~# yum -y install httpd mod_ssl
+root@idp:~# a2enmod ssl headers proxy proxy_ajp
 </code>
-=== SLES 11/12, OpenSUSE Leap 15.1 ===
+Außerdem braucht der Web Server Zugriff auf die Zertifikatsschlüssel:
-Apache wird als Proxy vor Tomcat via AJP verwendet. In ''/etc/sysconfig/apache2'' muss bei APACHE_MODULES proxy //vor// proxy_ajp stehen. Außerdem muss ''APACHE_SERVER_FLAGS="SSL"'' gesetzt sein.
-==== Apache-Module aktivieren ====
 <code bash>
-root@idp:~# a2enmod ssl headers proxy proxy_ajp
+root@idp:~# usermod -aG ssl-cert www-data
 </code>
-Abschließend muss der Web Server neu gestartet werden
+Abschließend muss der Web Server neu gestartet werden:
 <code bash>
 root@idp:~# systemctl restart apache2
@@ Zeile 93: / Zeile 91: @@
   # Die Zertifikatsdatei enthält die vollständige Kette, vgl.
   # http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatechainfile
+  # ACHTUNG: Wenn Sie für die SAML-Kommunikation ein anderes, länger laufendes Zertifikat
+  # als für den Webserver verwenden, müssen Sie hier dieses SAML-Zertifikat eintragen.
+  # Siehe unten bei "Backchannel Requests".
   SSLCertificateFile      /etc/ssl/localcerts/idp.uni-beispiel.crt.pem
   SSLCertificateKeyFile   /etc/ssl/private/idp.uni-beispiel.key.pem
@@ Zeile 267: / Zeile 268: @@
 </LocationMatch>
 </code>
+===== Besonderheiten bei Backchannel Requests =====
+Der Backchannel auf Port 8443 für die Server-to-Server-Kommunikation ist für eine funktionierende IdP-Konfiguration heutzutage nicht mehr zwingend nötig. Die obige Webserver-Konfiguration zeigt den Standardfall, in dem auf Port 8443 dasselbe Zertifikat verwendet wird wie auf Port 443. Diese Webserver-Konfiguration kann bei manchen Service Providern zu Problemen führen, wenn für die SAML-Kommunikation beim IdP ein abweichendes Zertifikat verwendet wird (getestet nur mit Shibboleth SP):
+Wenn ein Shibboleth Service Provider eine [[https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2065335187/ExplicitKeyTrustEngine|explizite Key Trust Engine]] gesetzt hat, dann holt er das IdP-Zertifikat, dem er vertraut, direkt aus den IdP-Metadaten. Dort findet er das Zertifikat, dass für die SAML-Kommunikation mit dem IdP verwendet werden soll. Wenn nun das Webserver- und das SAML-Zertifkat nicht identisch sind, sondern wenn z.B. für die SAML-Kommunikation ein selbstsigniertes Zertifikat verwendet wird, kommt es bei der Zertifikatsvalidierung zu einem Fehler, wenn
+  * eine Attribute Query auf Port 8443 gestellt wird oder
+  * ein Single Logout Request via SOAP auf Port 8443 gestellt wird.
+Stellt derselbe SP die beiden Anfragen an Port 443, so ignoriert er das fehlende Vertrauen und baut eine Verbindung zum IdP auf, obwohl das Zertifikat am Webserver dem in den Metadaten publizierten Zertifikat nicht entspricht.
+Um sicherzustellen, dass ein Shibboleth SP mit gesetzter Key Trust Engine auch die genannten Backchannel-Requests absetzen kann, können Sie am Backchannel das Zertifikat einsetzen, das für die SAML-Kommunikation in den Metadaten publiziert ist.
+<file apache /etc/apache2/sites-enabled/idp.uni-beispiel.de.conf>
+<VirtualHost IDP-IP-ADRESSE:443 [IDP-IPv6-ADRESSE]:443>
+  ServerName              idp.uni-beispiel.de
+  SSLEngine on
+  SSLCertificateFile      /etc/ssl/localcerts/idp.uni-beispiel.crt.pem
+  SSLCertificateKeyFile   /etc/ssl/private/idp.uni-beispiel.key.pem
+  # REST WIE OBEN
+</VirtualHost>
+################################################
+<VirtualHost IDP-IP-ADRESSE:8443 [IDP-IPv6-ADRESSE]:8443>
+  # Hier muss der Port im Servername genannt werden,
+  # damit das abweichende Zertifikat genutzt wird.
+  ServerName              idp.uni-beispiel.de:8443
+  SSLEngine on
+  SSLCertificateFile      /etc/ssl/localcerts/idp.saml-cert.crt.pem
+  SSLCertificateKeyFile   /etc/ssl/private/idp.saml-cert.key.pem
+  # REST WIE OBEN
+</VirtualHost>
+</file>
 ===== Testen der Verbindung Apache --> Tomcat =====
@@ Zeile 286: / Zeile 327: @@
     * [[https://www.ssllabs.com/ssltest/]]
-Weiter geht es mit der [[de:shibidp:install|Installation des Shibboleth IdP]].
+{{tag>idp4 tutorial apache webserver included-in-ansible}}

idp4 tutorial apache webserver included-in-ansible