Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung		 Vorhergehende Überarbeitung
de:shibidp:config-ecp [2020/04/14 13:42] – angelegt 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 Im Moment gängigen BW-Sync&Share-Clients kommen mit der default-ECP-Variante wie sie der Shibboleth IdP +===== Entweder: ECP-Endpunkt mit Apache Basic-Auth schützen =====
-mitbringt leider nicht zurecht (Ausnahme: der Powerfolder Iphone-Client scheint zu funktionieren). +
-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):+
  
-==== Basic-Auth mithilfe von Apache ====+Authentifizierung per LDAP im Apache aktivieren:
  
-ECP-Endpoint per Basic-Auth schützen:+<code bash> 
 +root@idp:~# a2enmod authnz_ldap 
 +root@idp:~# systemctl reload apache2 
 +</code>
  
-<file html /etc/apache2/sites-available/idp.hochschule-XY.de.conf> +<file apache /etc/apache2/sites-available/idp.hochschule-XY.de.conf>
-# +
-# Definition des LDAP-Server-Root-CA-Zertifikates +
-# +
-# ACHTUNG:+
 # #
-# - 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 40: 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 54: 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 84: Zeile 148:
 ===== ECP einschränken auf einzelne SPs ===== ===== ECP einschränken auf einzelne SPs =====
  
-Wer die ECP-Unterstützung auf einzelne SPs einschränken möchte (aus unserer Sicht nicht nötig und hier nur der Vollständigkeit halber erwähnt, aber falls jemand ein Szenario kennt in dem das sinnvoll ist, bitte melden), muss in ''/opt/shibboleth-idp/conf/relying-party.xml'' im Abschnitt DefaultRelyingParty die Referenz auf das Bean ''SAML2.ECP'' auskommentieren und in der Liste der RelyingPartyOverrides eine Konfiguration für diese SPs hinzufügen. 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]]. \\ Hier ein Beispiel für bwIDM:+ 
 +Mit diesem Beispiel erlauben Sie den Zugriff auf die ECP-Schnittstelle nur für bwIDM-SPs:
  
 <file xml /opt/shibboleth-idp/conf/relying-party.xml> <file xml /opt/shibboleth-idp/conf/relying-party.xml>
Zeile 133: Zeile 198:
 </file> </file>
  
 +{{tag>idp4 ecp syncandshare}}
  • Zuletzt geändert: vor 4 Jahren