Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
de:shibidp:prepare-http [2020/04/06 15:08] – Silke Meyerde: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 ->
  
-<callout type="danger" title="Firewall"> +====== IdP-Vorarbeiten: Webserver ====== 
-Die TCP-Ports 443 und 8443 müssen auf dem IdP für eingehende Zugriffe geöffnet sein!+ 
 +<callout color="#ff9900" title="Firewall"> 
 +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> </callout>
  
Zeile 9: Zeile 11:
 ==== Installation ==== ==== Installation ====
  
-=== Debian 10 ===+=== Debian 12 ===
  
 <code bash> <code bash>
Zeile 15: Zeile 17:
 </code> </code>
  
-=== RHEL 6/CentOS 7 ===+ 
 +==== Apache-Module aktivieren ====
  
 <code bash> <code bash>
-yum -y install httpd mod_ssl+root@idp:~# a2enmod ssl headers proxy proxy_ajp
 </code> </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> <code bash>
-root@idp:~# a2enmod ssl +root@idp:~# usermod -aG ssl-cert www-data
-root@idp:~# a2enmod headers +
-root@idp:~# a2enmod proxy +
-root@idp:~# a2enmod proxy_ajp+
 </code> </code>
  
-Abschließend muss der Web Server neu gestartet werden+Abschließend muss der Web Server neu gestartet werden:
 <code bash> <code bash>
 root@idp:~# systemctl restart apache2 root@idp:~# systemctl restart apache2
Zeile 96: Zeile 91:
   # Die Zertifikatsdatei enthält die vollständige Kette, vgl.   # Die Zertifikatsdatei enthält die vollständige Kette, vgl.
   # http://httpd.apache.org/docs/current/mod/mod_ssl.html#sslcertificatechainfile   # 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   SSLCertificateFile      /etc/ssl/localcerts/idp.uni-beispiel.crt.pem
   SSLCertificateKeyFile   /etc/ssl/private/idp.uni-beispiel.key.pem   SSLCertificateKeyFile   /etc/ssl/private/idp.uni-beispiel.key.pem
Zeile 270: Zeile 268:
 </LocationMatch> </LocationMatch>
 </code> </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 ===== ===== Testen der Verbindung Apache --> Tomcat =====
Zeile 279: Zeile 317:
  
 Funktioniert die Weiterleitung, dann bekommen Sie eine Fehlermeldung "HTTP Status 404 - /idp/" oder (je nach Tomcat-Version) eine weiße Seite vom Tomcat zu sehen, da das IdP-Servlet im Tomcat noch nicht aktiv ist. Die Weiterleitung ist damit aber erfolgreich getestet! Funktioniert die Weiterleitung, dann bekommen Sie eine Fehlermeldung "HTTP Status 404 - /idp/" oder (je nach Tomcat-Version) eine weiße Seite vom Tomcat zu sehen, da das IdP-Servlet im Tomcat noch nicht aktiv ist. Die Weiterleitung ist damit aber erfolgreich getestet!
-Kommt eine Apache-Fehlermeldung (diese sollte dann auch im obigen Apache-Log erscheinen) dann stimmt die Apache-Configuration noch nicht! Bitte dann nochmal obige Punkte sorgfältig durchgehen.+Kommt eine Apache-Fehlermeldung, dann stimmt die Apache-Konfiguration noch nicht. Bitte dann nochmal obige Punkte sorgfältig durchgehen.
  
 Anmerkungen: Anmerkungen:
-  * Achten Sie bitte darauf, dass sich die SSL-Direktiven tatsächlich in einem VirtualHost-Kontext befinden und **nicht** im Location-Kontext. (Mehr dazu im [[https://www.aai.dfn.de/aktuelles/newsansicht/article/emfohlene-konfigurationsaenderung-fuer-den-shibboleth-idp-83/|Archiv]]). + 
-  * stellen Sie sicher dass die Apache-SSL-Konfiguration aktuellen Sicherheitsstandards entspricht! Details dazu übersteigen den Rahmen diese Anleitung. Hilfreiche Seiten:+  * Bitte stellen Sie sicher dass die Apache-SSL-Konfiguration aktuellen Sicherheitsstandards entspricht! Details dazu übersteigen den Rahmen diese Anleitung. Hilfreiche Seiten:
     * [[https://ssl-config.mozilla.org/]]     * [[https://ssl-config.mozilla.org/]]
     * [[https://www.dfn-cert.de/]]     * [[https://www.dfn-cert.de/]]
-    * https://blog.pki.dfn.de/2015/03/mehr-privacy-fuer-den-nutzer-ocsp-stapling/]] 
     * [[https://blog.pki.dfn.de/]]     * [[https://blog.pki.dfn.de/]]
     * [[https://www.ssllabs.com/ssltest/]]     * [[https://www.ssllabs.com/ssltest/]]
  
-Weiter geht es mit [[de:shibidp3install|Installation Shibboleth IdP]]+{{tag>idp4 tutorial apache webserver included-in-ansible}}
  • Zuletzt geändert: vor 5 Jahren