Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp3ecp [2017/03/24 11:20] – 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: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']].
-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]].
-===== 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
-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 /etc/apache2/sites-available/idp.hochschule-XY.de.conf>
-LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
-<VirtualHost *:443>
-  ServerName              idp.hochschule-XY.de:443
-  ...
-  # ECP-Config für Sync&Share-Clients
-  <Location /idp/profile/SAML2/SOAP/ECP>
-    AuthType Basic
-    AuthName "idp.hochschule-XY.de - ECP profile"
-    AuthBasicProvider ldap
-    AuthLDAPURL "ldaps://ldap.hochschule-XY.de/ou=people,dc=hochschule-xy,dc=de?uid?sub"
-    AuthLDAPBindDN "cn=idp,cn=systemusers,dc=hochschule-xy,dc=de"
-    AuthLDAPBindPassword "geheim007"
-    Require valid-user
-  </Location>
-</VirtualHost>
-</file>
-Authentifizierung per LDAP im Apache aktivieren:
-<code bash>
-root@idp:~# a2enmod authnz_ldap
-root@idp:~# systemctl reload apache2
-</code>
-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 /edit-webapp/WEB-INF bearbeiten): \\
-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"
-**2. Context Fragment in Tomcat-Konfiguration anpassen.** \\
-Das sieht dann ungefähr so aus (appName, Pfade etc. ggf. anpassen):
-<file xml /etc/tomcat8/Catalina/localhost/idp.xml>
-<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
-/etc/default/tomcat8):
-<file bash /etc/default/tomcat8>
-JAVA_OPTS=" ... -Djava.security.auth.login.config=file:/opt/shibboleth-idp/login.config
-..."
-</file>
-**4. /opt/shibboleth-idp/login.config**
-** ACHTUNG: die Java-Klasse ist eine andere als bei der gewohnten login.config des IdP 2.x !!**
-<file javascript /opt/shibboleth-idp/login.config>
-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:
-- WARN [org.opensaml.soap.soap11.decoder.http.impl.HTTPSOAP11Decoder:146] - Saw
-unsupported request Content-Type: text/plain; charset=ISO-8859-1
-- 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 (nicht empfohlen, 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
-[[de:shibidp3storage|eingeschränkten Freigabe der PersistentID]]. \\ Hier ein Beispiel für bwIDM:
-<file xml /opt/shibboleth-idp/conf/relying-party.xml>
-<bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
-  <property name="profileConfigurations">
-    <list>
-        <bean parent="Shibboleth.SSO"
-              p:postAuthenticationFlows="#{{'terms-of-use', 'attribute-release'}}"
-              p:includeAttributeStatement="true" />
-          <ref bean="SAML1.AttributeQuery" />
-          <ref bean="SAML1.ArtifactResolution" />
-          <bean parent="SAML2.SSO"
-                p:nameIDFormatPrecedence="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
-                p:postAuthenticationFlows="#{{'terms-of-use', 'attribute-release'}}" />
-          <ref bean="SAML2.Logout" />
-          <ref bean="SAML2.ArtifactResolution" />
-    </list>
-  </property>
-</bean>
-<util:list id="shibboleth.RelyingPartyOverrides">
- <bean parent="RelyingPartyByTag">
-   <constructor-arg name="candidates">
-     <list>
-        <bean parent="TagCandidate" c:name="http://macedir.org/entity-category"
-              p:values="http://aai.dfn.de/category/bwidm-member"/>
-     </list>
-   </constructor-arg>
-   <property name="profileConfigurations">
-     <list>
-        <ref bean="SAML2.ECP" />
-        <ref bean="SAML2.AttributeQuery" />
-        <bean parent="SAML2.SSO"
-              p:postAuthenticationFlows="#{{'terms-of-use', 'attribute-release'}}"
-              p:nameIDFormatPrecedence="#{{'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'}}"
-                   />
-        <ref bean="SAML2.Logout" />
-        <ref bean="SAML2.ArtifactResolution" />
-     </list>
-   </property>
- </bean>
-</util:list>
-</file>