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/09 17:15]
Raoul Gunnar Borenius
de:shibidp3ecp [2019/10/10 15:07] (aktuell)
Silke Meyer
Zeile 1: Zeile 1:
-====== Enhanced Client ​and Proxy (ECP) ======+====== Enhanced Client ​or Proxy (ECP) ====== 
 + 
 +Die grundlegenden Konzepte sind im [[https://​wiki.shibboleth.net/​confluence/​display/​CONCEPT/​ECP|Shibboleth Wiki dokumentiert]].
  
 ECP ist im IdP 3.x out-of-the box aktiv. ECP ist im IdP 3.x out-of-the box aktiv.
Zeile 18: Zeile 20:
 ===== ECP für BWSync&​Share ===== ===== ECP für BWSync&​Share =====
  
-Die Im Moment gängigen BW-Sync&​Share-Clients ​erwarten z.B. dass der ECP-Endpunkt mit Basic-Auth geschützt ​ist+Die Im Moment gängigen BW-Sync&​Share-Clients ​kommen mit der default-ECP-Variante wie sie der Shibboleth IdP 
-Damit diese bedient werden können muss das nachgerüstet ​werden:+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 ==== ==== Basic-Auth mithilfe von Apache ====
Zeile 26: Zeile 31:
  
 <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 54: Zeile 71:
 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.
  
 +==== Probleme mit Sync&​Share seit Version 3.3.x ====
  
-==== Alternativ: Basic-Auth mithilfe von Tomcat (nicht mehr empfohlen da die Apache-Variante einfacher ist) ====+Ältere Powerfolder-Clients haben Problem bei der ECP-Kommunikation mit dem IdP 3.3.1.
  
-**1web.xml** (unter /​edit-webapp/​WEB-INF bearbeiten):​ \\  +Powerfolder hat hier im Juni 2017 nachgebesssert,​ Bitte achten Sie darauf dass Sie den 
-Die beiden Blöcke am Ende ent-kommentieren:​ "​Uncomment to use container managed +neuesten Client im Einsatz haben damit der Zugriff funktioniert.
-authentication"​ und "​Uncomment if you want BASIC auth managed by the container"​+
  
-**2Context Fragment in Tomcat-Konfiguration anpassen.** \\ +==== Probleme mit bwLehrpool seit Version 3.3.x ====
-Das sieht dann ungefähr so aus (appName, Pfade etc. ggf. anpassen):+
  
-<file xml /​etc/​tomcat8/​Catalina/​localhost/​idp.xml> +Auch der bwLehrpool-Client hatte Probleme mit der Kommuniktaion zum IdP 3.3.1 weil ein falschen Content-Type verwendet wurde (http://shibboleth.1660669.n2.nabble.com/ECP-issue-with-current-opensaml-soap-impl-td7629351.html)
-<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>​+
  
-**3. Tomcat ​den Pfad zur JAAS login.config als Startparameter mitgeben** (unter Debian ​in +Sofern Sie noch nicht den neuesten Client ​in Verwendung haben wenden Sie sich bitte an [[https://www.bwlehrpool.de/|bwLehrpool]]. 
-/etc/default/tomcat8):+===== Funktionstest =====
  
-<file bash /etc/default/​tomcat8>​ +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 WikiDas folgende Beispiel bezieht sich auf ecp.sh:
-JAVA_OPTS=" ​... -Djava.security.auth.login.config=file:​/opt/shibboleth-idp/login.config +
-..." +
-</​file>​+
  
-**4/​opt/​shibboleth-idp/​login.config**+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.
  
-** ACHTUNGdie Java-Klasse ist eine andere wie bei der gewohnten login.config des IdP 2.x !!**+<​code>​ 
 +["​Campus01"​]="​https://idp.example.org/​idp/​profile/​SAML2/​SOAP/​ECP"​ 
 +</​code>​
  
-<file javascript /​opt/​shibboleth-idp/​login.config+Dann kann der Client mit einem beliebigen (Test-)User (hier: "​tuser"​) verwendet werden: 
-ShibUserPassAuth { + 
-   org.ldaptive.jaas.LdapLoginModule required +<code
-      ldapUrl="​..." +user@idp:​~# ​./ecp.sh -d Campus01 https://​testsp3.aai.dfn.de/​ecp-test/​index.txt tuser 
-      ​ssl="​true"​ +</​code>​ 
-      ​bindDn="​..."​ + 
-      ​bindCredential="​..." +Beim danach erscheinenden Passwort-Prompt das Passwort des (Test-)Users eingebenWenn alles funktioniert,​ wird im Anschluss an allerlei Debug-Output ein "ok" ​zurückgegeben.
-      baseDn="..." +
-      userFilter="​uid={user}"​ +
-      logCredentials="​false"​ +
-   ; +
-}; +
-</​file>​+
  
 ===== ECP einschränken auf einzelne SPs ===== ===== ECP einschränken auf einzelne SPs =====
  
-Wer die ECP-Unterstützung auf einzelne SPs einschränken möchte (nicht ​empfohlen, aber falls jemand ein +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 
-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: [[de:​shibidp3storage|eingeschränkten Freigabe der PersistentID]]. \\ Hier ein Beispiel für bwIDM:
  
  • Zuletzt geändert: vor 3 Jahren