Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung | ||
de:shibidp3ecp [2017/03/24 11:21] – Raoul Gunnar Borenius | de:shibidp:ecp [2023/03/02 14:40] (aktuell) – Inhalt jetzt nur noch unter de:shibidp:config-ecp Silke Meyer | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== Enhanced Client and Proxy (ECP) ====== | ||
- | |||
- | ECP ist im IdP 3.x out-of-the box aktiv. | ||
- | |||
- | Achten Sie nur darauf dass das ECP-SSO-Binding des IdPs in den DFN-AAI-Metadaten auch angegeben ist: | ||
- | |||
- | {{de: | ||
- | |||
- | Fehlt dies, finden ECP-Clients den IdP nicht wenn Sie sich anmelden wollen. | ||
- | |||
- | Zum Testen eignet sich das vom CILogon Projekt bereitgestellte [[http:// | ||
- | |||
- | |||
- | Siehe auch die [[https:// | ||
- | |||
- | Ob die IdP-seitigen Voreinstellungen für den ECP-Support ausreichen, hängt letztlich vom Verhalten der eingesetzten Clients ab, siehe hierzu die [[https:// | ||
- | |||
- | ===== ECP für BWSync& | ||
- | |||
- | Die Im Moment gängigen BW-Sync& | ||
- | 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 ==== | ||
- | |||
- | ECP-Endpoint per Basic-Auth schützen: | ||
- | |||
- | <file html / | ||
- | LDAPTrustedGlobalCert CA_BASE64 / | ||
- | < | ||
- | ServerName | ||
- | ... | ||
- | | ||
- | # ECP-Config für Sync& | ||
- | < | ||
- | AuthType Basic | ||
- | AuthName " | ||
- | AuthBasicProvider ldap | ||
- | AuthLDAPURL " | ||
- | AuthLDAPBindDN " | ||
- | AuthLDAPBindPassword " | ||
- | Require valid-user | ||
- | </ | ||
- | </ | ||
- | </ | ||
- | |||
- | Authentifizierung per LDAP im Apache aktivieren: | ||
- | |||
- | <code bash> | ||
- | root@idp:~# a2enmod authnz_ldap | ||
- | root@idp:~# systemctl reload apache2 | ||
- | </ | ||
- | |||
- | 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 fail2ban-Seite in diesem Wiki. | ||
- | |||
- | |||
- | ==== Alternativ: Basic-Auth mithilfe von Tomcat (nicht mehr empfohlen da die Apache-Variante einfacher ist) ==== | ||
- | |||
- | **1. web.xml** (unter / | ||
- | Die beiden Blöcke am Ende ent-kommentieren: | ||
- | authentication" | ||
- | |||
- | **2. Context Fragment in Tomcat-Konfiguration anpassen.** \\ | ||
- | Das sieht dann ungefähr so aus (appName, Pfade etc. ggf. anpassen): | ||
- | |||
- | <file xml / | ||
- | <Context docBase="/ | ||
- | | ||
- | | ||
- | | ||
- | | ||
- | <Realm className=" | ||
- | </ | ||
- | </ | ||
- | |||
- | **3. Tomcat den Pfad zur JAAS login.config als Startparameter mitgeben** (unter Debian in | ||
- | / | ||
- | |||
- | <file bash / | ||
- | JAVA_OPTS=" | ||
- | ..." | ||
- | </ | ||
- | |||
- | **4. / | ||
- | |||
- | ** ACHTUNG: die Java-Klasse ist eine andere als bei der gewohnten login.config des IdP 2.x !!** | ||
- | |||
- | <file javascript / | ||
- | ShibUserPassAuth { | ||
- | | ||
- | ldapUrl=" | ||
- | ssl=" | ||
- | bindDn=" | ||
- | bindCredential=" | ||
- | baseDn=" | ||
- | userFilter=" | ||
- | logCredentials=" | ||
- | ; | ||
- | }; | ||
- | </ | ||
- | |||
- | |||
- | ==== Probleme mit Sync& | ||
- | |||
- | Aus Bayern haben wir Probleme mit dem Zugriff auf den bayerischen Sync& | ||
- | 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: | ||
- | unsupported request Content-Type: | ||
- | 523 - ERROR [org.opensaml.profile.action.impl.DecodeMessage: | ||
- | DecodeMessage: | ||
- | org.opensaml.messaging.decoder.MessageDecodingException: | ||
- | charset=ISO-8859-1' | ||
- | org.opensaml.soap.soap11.decoder.http.impl.HTTPSOAP11Decoder.validateHttpRequest(HTTPSOAP11Decoder.j | ||
- | ava:147 | ||
- | |||
- | |||
- | Problem ist die " | ||
- | Content-Type-Prüfung durchgeführt, | ||
- | |||
- | Man kann entweder wieder auf IdP 3.2.x zurückgehen oder als Workaround die " | ||
- | opensaml-soap-impl-3.3.0.jar (unter ../ | ||
- | opensaml-soap-impl-3.2.0.jar (welche im " | ||
- | ../ | ||
- | 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 ''/ | ||
- | [[de: | ||
- | |||
- | <file xml / | ||
- | |||
- | <bean id=" | ||
- | < | ||
- | < | ||
- | <bean parent=" | ||
- | p: | ||
- | p: | ||
- | <ref bean=" | ||
- | <ref bean=" | ||
- | <bean parent=" | ||
- | p: | ||
- | p: | ||
- | <ref bean=" | ||
- | <ref bean=" | ||
- | </ | ||
- | </ | ||
- | </ | ||
- | |||
- | < | ||
- | |||
- | < | ||
- | < | ||
- | < | ||
- | <bean parent=" | ||
- | p: | ||
- | </ | ||
- | </ | ||
- | < | ||
- | < | ||
- | <ref bean=" | ||
- | <ref bean=" | ||
- | <bean parent=" | ||
- | p: | ||
- | p: | ||
- | /> | ||
- | <ref bean=" | ||
- | <ref bean=" | ||
- | </ | ||
- | </ | ||
- | </ | ||
- | |||
- | </ | ||
- | |||
- | </ | ||