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:shibidp3ecp [2017/03/24 11:21]
Raoul Gunnar Borenius
de:shibidp3ecp [2020/05/14 09:24] (aktuell)
Silke Meyer [ECP für BWSync&Share]
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 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. 
 +ECP ist im 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 14:
 ===== 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 21:
  
 <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 58:
 </​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-1' ​was 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 (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  +Hier ein Beispiel für bwIDM:
-[[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 182: Zeile 132:
 </​file>​ </​file>​
  
 +{{tag>​idp3 idp4 fixme}}
  • Zuletzt geändert: vor 3 Jahren