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
Nächste ÜberarbeitungBeide Seiten der Revision
de:shibidp3ecp [2017/03/24 11:20] Raoul Gunnar Boreniusde:shibidp:ecp [2020/10/14 16:00] – ↷ Seite von de:shibidp3ecp nach de:shibidp:ecp verschoben und umbenannt Silke Meyer
Zeile 1: Zeile 1:
-====== Enhanced Client and Proxy (ECP) ======+====== Enhanced Client or Proxy (ECP) ======
  
-ECP ist im IdP 3.x out-of-the box aktiv.+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 dokumentiertECP ist im Shibboleth-IdP standardmäßig aktiv.
  
-Achten Sie nur darauf dass das ECP-SSO-Binding des IdPs in den DFN-AAI-Metadaten auch angegeben ist:+Achten Sie daraufdass 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}}
  
-Fehlt dies, finden ECP-Clients den IdP nicht wenn Sie sich anmelden wollen. 
-  
 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']].
- 
- 
-Siehe auch die [[https://wiki.shibboleth.net/confluence/display/IDP30/ECPConfiguration|Dokumentation im Shibboleth Wiki]]. 
  
 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]]. 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]].
Zeile 18: Zeile 13:
 ===== ECP für BWSync&Share ===== ===== ECP für BWSync&Share =====
  
-Die Im Moment gängigen BW-Sync&Share-Clients kommen  mit der default-ECP-Variante wie sie der Shibboleth IdP +Viele BW-Sync&Share-Clients kommen mit der ECP-Variante des Shibboleth IdP 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. Wir empfehlen die deutlich einfachere Apache-Variante.
-mitbringt 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, wobei die Apache variante aus unserer Sicht +
-deutlich simpler ist:+
  
 ==== Basic-Auth mithilfe von Apache ==== ==== Basic-Auth mithilfe von Apache ====
Zeile 28: Zeile 20:
  
 <file html /etc/apache2/sites-available/idp.hochschule-XY.de.conf> <file html /etc/apache2/sites-available/idp.hochschule-XY.de.conf>
 +#
 +# Definition des LDAP-Server-Root-CA-Zertifikates
 +#
 +# ACHTUNG:
 +#
 +# - kann nicht innerhalb des VirtualHost stehen
 +# - hier im Beispiel von der DFN-PKI Generation 2, muss zur ROOT-CA des LDAP-Server-
 +#   Zertifikates passen!
 +# - stellen Sie sicher dass in /etc/ldap/ldap.conf kein anderes ROOT-CA-Zertifikat
 +#   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
 +
 <VirtualHost *:443> <VirtualHost *:443>
   ServerName              idp.hochschule-XY.de:443   ServerName              idp.hochschule-XY.de:443
Zeile 53: Zeile 57:
 </code> </code>
  
-Da dieser Endpunkt weltweit erreichbar sein muss können hier auch Brute-Force-Passwort-Angriffe auftreten. +Da dieser Endpunkt weltweit erreichbar sein musskönnen hier auch Brute-Force-Passwort-Angriffe auftreten. Diesen sollten ebenfalls mithilfe von fail2ban begegnet werden, siehe die fail2ban-Seite in diesem Wiki.
-Diesen sollten ebenfalls mithilfe von fail2ban begegnet werden, siehe die fail2ban-Seite in diesem Wiki.+
  
 +===== Funktionstest =====
  
-==== AlternativBasic-Auth mithilfe von Tomcat (nicht mehr empfohlen da die Apache-Variante einfacher ist) ====+Um die grundsätzliche Funktionalität zu testen kann einer der aus der Shibboleth Community bereitgestellten Clients verwendet werden, siehe die [[https://wiki.shibboleth.net/confluence/display/SHIB2/Contributions#Contributions-simplebash|Contributions-Seite]] im Shibboleth Wiki. Das folgende Beispiel bezieht sich auf ecp.sh:
  
-**1web.xml** (unter /edit-webapp/WEB-INF bearbeiten): \\  +Zunächst die Dokumentation in den ersten Zeilen des Skripts durchlesen und unter ecp_endpoints einen Alias für den zu testenden IdP setzen, z.B.
-Die beiden Blöcke am Ende ent-kommentieren: "Uncomment to use container managed +
-authentication" und "Uncomment if you want BASIC auth managed by the container"+
  
-**2Context Fragment in Tomcat-Konfiguration anpassen.** \\ +<code> 
-Das sieht dann ungefähr so aus (appName, Pfade etc. ggf. anpassen):+["Campus01"]="https://idp.example.org/idp/profile/SAML2/SOAP/ECP" 
 +</code>
  
-<file xml /etc/tomcat8/Catalina/localhost/idp.xml> +Dann kann der Client mit einem beliebigen (Test-)User (hier: "tuser") verwendet werden:
-<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>+
  
-**3Tomcat den Pfad zur JAAS login.config als Startparameter mitgeben** (unter Debian in +<code> 
-/etc/default/tomcat8):+user@idp:~# ./ecp.sh -d Campus01 https://testsp3.aai.dfn.de/ecp-test/index.txt tuser 
 +</code>
  
-<file bash /etc/default/tomcat8> +Beim danach erscheinenden Passwort-Prompt das Passwort des (Test-)Users eingebenWenn alles funktioniert, wird im Anschluss an allerlei Debug-Output ein "ok" zurückgegeben.
-JAVA_OPTS=" ... -Djava.security.auth.login.config=file:/opt/shibboleth-idp/login.config +
-..." +
-</file>+
  
-**4. /opt/shibboleth-idp/login.config**+===== ECP einschränken auf einzelne SPs =====
  
-** ACHTUNG: die Java-Klasse ist eine andere als bei der gewohnten login.config des IdP 2.x !!**+Aus unserer Sicht ist es nicht nötig, die ECP-Unterstützung auf einzelne SPs einzuschränkenDer Vollständigkeit halber sei hier aber erwähnt, wie das geht:
  
-<file javascript /opt/shibboleth-idp/login.config> +Kommentieren Sie ''/opt/shibboleth-idp/conf/relying-party.xml'' im Abschnitt DefaultRelyingParty die Referenz auf das Bean ''SAML2.ECP'' ausFügen Sie in der Liste der RelyingPartyOverrides eine Konfiguration für diese SPs hinzu.
-ShibUserPassAuth { +
-   org.ldaptive.jaas.LdapLoginModule required +
-      ldapUrl="..." +
-      ssl="true" +
-      bindDn="..." +
-      bindCredential="..." +
-      baseDn="..." +
-      userFilter="uid={user}" +
-      logCredentials="false" +
-   ; +
-}; +
-</file> +
- +
- +
-==== Probleme mit Sync&Share seit Version 3.3.x ==== +
- +
-Aus Bayern haben wir Probleme mit dem Zugriff auf den bayerischen Sync&Share-Dienst nach Upgrade +
-auf IdP 3.3 gemeldet bekommen und geben den Workaround ungetestet weiter: +
- +
-Das Leibniz-Rechenzentrum hat einen Workaround erarbeitet. Im idp-process.log sieht man +
-bei dem Fehler folgende Einträge: +
- +
-522 - WARN [org.opensaml.soap.soap11.decoder.http.impl.HTTPSOAP11Decoder:146] - Saw +
-unsupported request Content-Type: text/plain; charset=ISO-8859-1 +
-523 - ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action +
-DecodeMessage: Unable to decode incoming request +
-org.opensaml.messaging.decoder.MessageDecodingException: Content-Type 'text/plain; +
-charset=ISO-8859-1was not a supported media type at +
-org.opensaml.soap.soap11.decoder.http.impl.HTTPSOAP11Decoder.validateHttpRequest(HTTPSOAP11Decoder.j +
-ava:147 +
- +
- +
-Problem ist die "Klasse" opensaml-soap-impl-3.3.0.jar. In dieser wird neuerdings eine +
-Content-Type-Prüfung durchgeführt, welche fehlschlägt. +
- +
-Man kann entweder wieder auf IdP 3.2.x zurückgehen oder als Workaround die "Klasse" +
-opensaml-soap-impl-3.3.0.jar (unter ../WEB-INF/lib) durch die Vorgängerversion +
-opensaml-soap-impl-3.2.0.jar (welche im "old-xxxxx"-Sicherungsverzeichnis unter +
-../WEB-INF/lib) liegt ersetzen (natürlich die aktuelle Version vorher wegsichern). Danach +
-einen ./build.sh durchführen und die Anmeldung sollte wieder funktionieren. Dieser +
-Workaround ist natürlich auf eigene Gefahr! +
- +
-===== ECP einschränken auf einzelne SPs =====+
  
-Wer die ECP-Unterstützung auf einzelne SPs einschränken möchte (nicht empfohlen, aber falls jemand ein +Hier ein Beispiel für bwIDM:
-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  +
-[[de:shibidp3storage|eingeschränkten Freigabe der PersistentID]]. \\ Hier ein Beispiel für bwIDM:+
  
 <file xml /opt/shibboleth-idp/conf/relying-party.xml> <file xml /opt/shibboleth-idp/conf/relying-party.xml>
Zeile 183: Zeile 131:
 </file> </file>
  
 +{{tag>idp3 idp4}}