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:config-ecp [2020/04/14 13:49] – Silke Meyerde:shibidp:config-ecp [2023/03/02 14:40] (aktuell) – Silke Meyer
Zeile 1: Zeile 1:
 ====== Enhanced Client or Proxy (ECP) ====== ====== Enhanced Client or Proxy (ECP) ======
  
-Die grundlegenden [[https://wiki.shibboleth.net/confluence/display/CONCEPT/ECP|Konzepte]] und die [[https://wiki.shibboleth.net/confluence/display/IDP30/ECPConfiguration|Konfiguration von ECP]] sind im Shibboleth Wiki dokumentiert. +Die ECP-Schnittstelle eines IdP ist für die Kommunikation mit nicht-browserbasierten Clients da. Das grundlegende [[https://wiki.shibboleth.net/confluence/display/CONCEPT/ECP|Konzept]] ist im Shibboleth Wiki dokumentiert. ECP ist im Shibboleth-IdP standardmäßig aktiv.
-ECP ist im IdP 3.x out-of-the box aktiv.+
  
 Achten Sie darauf, dass das ECP-SSO-Binding des IdPs in den DFN-AAI-Metadaten angegeben ist. Fehlt es, finden ECP-Clients den IdP nicht, wenn Sie sich anmelden wollen. Achten Sie darauf, dass das ECP-SSO-Binding des IdPs in den DFN-AAI-Metadaten angegeben ist. Fehlt es, finden ECP-Clients den IdP nicht, wenn Sie sich anmelden wollen.
  
-{{de:ecp.png}}+{{de:ecp.png|400}}
  
 Zum Testen eignet sich das vom CILogon Projekt bereitgestellte [[http://www.cilogon.org/ecp#TOC-A-Basic-ECP-IdP-Test-Script|Testscript 'testecp.sh']]. Zum Testen eignet sich das vom CILogon Projekt bereitgestellte [[http://www.cilogon.org/ecp#TOC-A-Basic-ECP-IdP-Test-Script|Testscript 'testecp.sh']].
  
-Ob die IdP-seitigen Voreinstellungen für den ECP-Support ausreichen, hängt letztlich vom Verhalten der eingesetzten Clients ab, siehe hierzu die [[https://wiki.shibboleth.net/confluence/display/IDP30/PasswordAuthnConfiguration#PasswordAuthnConfiguration-UserInterface|Dokumentation im Shibboleth Wiki]]. 
  
-===== ECP für BWSync&Share =====+<callout color="#ff9900" title="Schutz mit Basic-Auth nötig"> 
 +Viele Sync&Share-Clients kommen mit der ECP-Variante des Shibboleth IdP leider nicht zurecht. Der ECP-Endpunkt muss für diese Clients noch explizit mit Basic-Auth geschützt werden. Dies kann mithilfe von **Apache oder Tomcat** gemacht werden - einfacher ist die Apache-Variante. 
 +</callout>
  
-Die gängigen BW-Sync&Share-Clients kommen mit der default-ECP-Variante des Shibboleth IdP leider nicht zurecht. +===== Entweder: ECP-Endpunkt mit Apache Basic-Auth schützen =====
-Der ECP-Endpunkt muss für diese Clients noch explizit mit Basic-Auth geschützt werden. +
-Dies kann mithilfe von Apache oder Tomcat gemacht werden, wobei die Apache-Variante aus unserer Sicht +
-deutlich simpler ist (die Tomcat-Variante finden Sie rechts im Index falls Sie Tomcat ohne Apache betreiben):+
  
-<file html /etc/apache2/sites-available/idp.hochschule-XY.de.conf> +Authentifizierung per LDAP im Apache aktivieren: 
-# + 
-# Definition des LDAP-Server-Root-CA-Zertifikates +<code bash> 
-# +root@idp:~# a2enmod authnz_ldap 
-# ACHTUNG:+root@idp:~# systemctl reload apache2 
 +</code> 
 + 
 +<file apache /etc/apache2/sites-available/idp.hochschule-XY.de.conf>
 # #
-# - kann nicht innerhalb des VirtualHost stehen +# - Definition des LDAP-Server-Root-CA-Zertifikates außerhalb der VirtualHost-Direktive 
-# - hier am Beispiel der DFN-PKI, muss zur ROOT-CA des LDAP-Server-Zertifikates passen! +# - hier am Beispiel der DFN-PKI, bitte anpassen 
-# - stellen Sie sicher dass in /etc/ldap/ldap.conf kein anderes ROOT-CA-Zertifikat +# - Abweichende Einträge in /etc/ldap/ldap.conf überschreiben diesen Eintrag.
-#   eingetragen ist welches diesen Eintrag überschreiben würde!+
 # #
 LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
Zeile 35: Zeile 34:
   ServerName              idp.hochschule-XY.de:443   ServerName              idp.hochschule-XY.de:443
   ...   ...
-   
   # ECP-Config für Sync&Share-Clients   # ECP-Config für Sync&Share-Clients
   <Location /idp/profile/SAML2/SOAP/ECP>   <Location /idp/profile/SAML2/SOAP/ECP>
Zeile 49: Zeile 47:
 </file> </file>
  
-Authentifizierung per LDAP im Apache aktivieren:+===== Oder: ECP-Endpunkt mit Tomcat Basic-Auth schützen =====
  
-<code bash> +FIXME prüfen! 
-root@idp:~# a2enmod authnz_ldap + 
-root@idp:~# systemctl reload apache2 +Wir empfehlen, die ECP-Schnittstelle über den Webserver zu schützen, wenn dies in Ihrer Umgebung möglich ist. 
-</code>+ 
 +Zunächst aktivieren Sie folgende Blöcke in ''./edit-webapp/WEB-INF/web.xml'': 
 + 
 +<file xml ./edit-webapp/WEB-INF/web.xml> 
 +    ... 
 +    <!-- 
 +    Uncomment to use container managed authentication. The new servlet spec (3.1) 
 +    supports "**" as a wildcard syntax to avoid role usage, which is normally desirable. 
 +    Older containers usually support "*" when proprietary options are used (e.g., Jetty 
 +    requires setting the Strict property on the SecurityManager.) 
 +    --> 
 +    <security-constraint> 
 +        <display-name>Web Login Service</display-name> 
 +        <web-resource-collection> 
 +            <web-resource-name>user authentication</web-resource-name> 
 +            <url-pattern>/Authn/RemoteUser</url-pattern> 
 +            <url-pattern>/profile/SAML2/SOAP/ECP</url-pattern> 
 +            <http-method>POST</http-method>· 
 +        </web-resource-collection> 
 +        <auth-constraint> 
 +            <role-name>**</role-name> 
 +        </auth-constraint> 
 +        <user-data-constraint> 
 +            <transport-guarantee>CONFIDENTIAL</transport-guarantee>· 
 +        </user-data-constraint> 
 +    </security-constraint> 
 + 
 +    <!-- Uncomment if you want BASIC auth managed by the container. --> 
 +    <login-config> 
 +        <auth-method>BASIC</auth-method> 
 +        <realm-name>Web Login Service</realm-name> 
 +    </login-config> 
 +    ... 
 +</file> 
 + 
 +Passen Sie das Context Fragment in der Tomcat-Konfiguration an. Das sieht dann ungefähr so aus (appName, Pfade etc. ggf. anpassen): 
 + 
 +<file xml /etc/tomcat9/Catalina/localhost/idp.xml> 
 +<Context docBase="/opt/shibboleth-idp/war/idp.war" 
 +         privileged="true" 
 +         antiResourceLocking="false" 
 +         unpackWAR="true" 
 +         swallowOutput="true"> 
 +  <Realm className="org.apache.catalina.realm.JAASRealm" appName="ShibUserPassAuth"/> 
 +</Context> 
 +</file> 
 + 
 +Geben Sie Tomcat den Pfad zur JAAS login.config als Startparameter mit: 
 + 
 +<file bash /etc/default/tomcat9> 
 +JAVA_OPTS=" ... -Djava.security.auth.login.config=file:/opt/shibboleth-idp/login.config ..." 
 +</file> 
 + 
 +Legen Sie die Datei ''./login.config'' an: 
 + 
 +<file javascript /opt/shibboleth-idp/login.config> 
 +ShibUserPassAuth { 
 +   org.ldaptive.jaas.LdapLoginModule required 
 +      ldapUrl="..." 
 +      ssl="true" 
 +      bindDn="..." 
 +      bindCredential="..." 
 +      baseDn="..." 
 +      userFilter="uid={user}" 
 +      logCredentials="false" 
 +   ; 
 +}; 
 +</file> 
 + 
 +Starten Sie Tomcat neu.
  
 +<callout color="#ff9900" title="Schutz vor Brute-Force">
 Da dieser Endpunkt weltweit erreichbar sein muss, können hier auch Brute-Force-Passwort-Angriffe auftreten. Da dieser Endpunkt weltweit erreichbar sein muss, können hier auch Brute-Force-Passwort-Angriffe auftreten.
 Diesen sollten ebenfalls mithilfe von fail2ban begegnet werden, siehe die [[de:shibidp:fail2ban|fail2ban-Seite]] in diesem Wiki. Diesen sollten ebenfalls mithilfe von fail2ban begegnet werden, siehe die [[de:shibidp:fail2ban|fail2ban-Seite]] in diesem Wiki.
 +</callout>
  
 ===== Funktionstest ===== ===== Funktionstest =====
Zeile 79: Zeile 148:
 ===== ECP einschränken auf einzelne SPs ===== ===== ECP einschränken auf einzelne SPs =====
  
-Aus unserer Sicht ist es nicht nötig, die ECP-Unterstützung auf einzelne SPs einzuschränken. Der Vollständigkeit halber sei hier jedoch gezeigt, wie das geht: Sie müssten in ''/opt/shibboleth-idp/conf/relying-party.xml'' im Abschnitt ''DefaultRelyingParty'' die Referenz auf das Bean ''SAML2.ECP'' auskommentieren. Weiter unten fügen Sie in der Liste der ''RelyingPartyOverrides'' eine Konfiguration für die gewünschten SPs hinzu. Das funktioniert analog zur  +Aus unserer Sicht ist es nicht nötig, die ECP-Unterstützung auf einzelne SPs einzuschränken. Der Vollständigkeit halber sei hier jedoch gezeigt, wie das geht: Sie müssten in ''/opt/shibboleth-idp/conf/relying-party.xml'' im Abschnitt ''DefaultRelyingParty'' die Referenz auf das Bean ''SAML2.ECP'' auskommentieren. Weiter unten fügen Sie in der Liste der ''RelyingPartyOverrides'' eine Konfiguration für die gewünschten SPs hinzu.
-[[de:shibidp3storage|eingeschränkten Freigabe der PersistentID]].+
  
 Mit diesem Beispiel erlauben Sie den Zugriff auf die ECP-Schnittstelle nur für bwIDM-SPs: Mit diesem Beispiel erlauben Sie den Zugriff auf die ECP-Schnittstelle nur für bwIDM-SPs:
Zeile 130: Zeile 198:
 </file> </file>
  
 +{{tag>idp4 ecp syncandshare}}
  • Zuletzt geändert: vor 4 Jahren