Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:shibidp3ecp [2017/03/24 11:21] – Raoul Gunnar Borenius | de:shibidp3ecp [2020/04/16 08:59] – Silke Meyer | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== Enhanced Client | + | ====== Enhanced Client |
+ | Die grundlegenden [[https:// | ||
ECP ist im IdP 3.x out-of-the box aktiv. | 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 | + | 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: | {{de: | ||
- | Fehlt dies, finden ECP-Clients den IdP nicht wenn Sie sich anmelden wollen. | ||
- | |||
Zum Testen eignet sich das vom CILogon Projekt bereitgestellte [[http:// | 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:// | Ob die IdP-seitigen Voreinstellungen für den ECP-Support ausreichen, hängt letztlich vom Verhalten der eingesetzten Clients ab, siehe hierzu die [[https:// | ||
Zeile 18: | Zeile 14: | ||
===== ECP für BWSync& | ===== ECP für BWSync& | ||
- | Die Im Moment gängigen BW-Sync& | + | 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 | + | mitbringt leider nicht zurecht |
- | werden. Dies kann mithilfe von Apache oder Tomcat gemacht werden, wobei die Apache | + | Der ECP-Endpunkt muss für diese Clients noch explizit mit Basic-Auth geschützt werden. |
- | deutlich simpler ist: | + | Dies kann mithilfe von Apache oder Tomcat gemacht werden, wobei die Apache-Variante |
+ | 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 28: | Zeile 25: | ||
<file html / | <file html / | ||
+ | # | ||
+ | # 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- | ||
+ | # | ||
+ | # - stellen Sie sicher dass in / | ||
+ | # | ||
+ | # | ||
LDAPTrustedGlobalCert CA_BASE64 / | LDAPTrustedGlobalCert CA_BASE64 / | ||
+ | |||
< | < | ||
ServerName | ServerName | ||
Zeile 56: | Zeile 65: | ||
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& | ||
- | ==== 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. |
- | **1. web.xml** (unter / | + | Powerfolder hat hier im Juni 2017 nachgebesssert, |
- | Die beiden Blöcke am Ende ent-kommentieren: | + | neuesten Client im Einsatz haben damit der Zugriff funktioniert. |
- | authentication" | + | |
- | **2. Context 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 / | + | 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="/ | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | <Realm className=" | + | |
- | </ | + | |
- | </ | + | |
- | **3. Tomcat | + | Sofern Sie noch nicht den neuesten Client |
- | /etc/default/tomcat8): | + | ===== Funktionstest ===== |
- | <file bash /etc/default/ | + | 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/ |
- | JAVA_OPTS=" | + | |
- | ..." | + | |
- | </ | + | |
- | **4. / | + | 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. |
- | ** ACHTUNG: die Java-Klasse ist eine andere als bei der gewohnten login.config des IdP 2.x !!** | + | < |
+ | [" | ||
+ | </ | ||
- | <file javascript / | + | Dann kann der Client mit einem beliebigen (Test-)User (hier: |
- | ShibUserPassAuth { | + | |
- | | + | |
- | ldapUrl="..." | + | |
- | ssl=" | + | |
- | bindDn=" | + | |
- | bindCredential=" | + | |
- | baseDn=" | + | |
- | userFilter=" | + | |
- | logCredentials=" | + | |
- | ; | + | |
- | }; | + | |
- | </ | + | |
+ | < | ||
+ | user@idp:~# ./ecp.sh -d Campus01 https:// | ||
+ | </ | ||
- | ==== Probleme mit Sync& | + | Beim danach erscheinenden Passwort-Prompt das Passwort des (Test-)Users eingeben. Wenn alles funktioniert, |
- | + | ||
- | 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 "Klasse" | + | |
- | 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 ===== | ===== 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 | + | Wer die ECP-Unterstützung auf einzelne SPs einschränken möchte (aus unserer Sicht nicht nötig und hier nur der Vollständigkeit |
[[de: | [[de: | ||
Zeile 182: | Zeile 146: | ||
</ | </ | ||
+ | {{tag> |