Zeige QuelltextÄltere VersionenLinks hierherNach oben Letzte ÄnderungenPer E-Mail sendenDruckenPermalink × Inhaltsverzeichnis Enhanced Client or Proxy (ECP) ECP für BWSync&Share Basic-Auth mithilfe von Apache Funktionstest ECP einschränken auf einzelne SPs Dies ist eine alte Version des Dokuments! Enhanced Client or Proxy (ECP) Die ECP-Schnittstelle eines IdP ist für die Kommunikation mit nicht-browserbasierten Clients da. Das grundlegende Konzept ist im Shibboleth Wiki dokumentiert. ECP ist im Shibboleth-IdP standardmäßig aktiv. 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. Zum Testen eignet sich das vom CILogon Projekt bereitgestellte Testscript 'testecp.sh'. Ob die IdP-seitigen Voreinstellungen für den ECP-Support ausreichen, hängt letztlich vom Verhalten der eingesetzten Clients ab, siehe hierzu die Dokumentation im Shibboleth Wiki. ECP für BWSync&Share 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. Basic-Auth mithilfe von Apache ECP-Endpoint per Basic-Auth schützen: /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 <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> Authentifizierung per LDAP im Apache aktivieren: 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. Funktionstest Um die grundsätzliche Funktionalität zu testen kann einer der aus der Shibboleth Community bereitgestellten Clients verwendet werden, siehe die Contributions-Seite im Shibboleth Wiki. Das folgende Beispiel bezieht sich auf ecp.sh: 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. ["Campus01"]="https://idp.example.org/idp/profile/SAML2/SOAP/ECP" Dann kann der Client mit einem beliebigen (Test-)User (hier: „tuser“) verwendet werden: user@idp:~# ./ecp.sh -d Campus01 https://testsp3.aai.dfn.de/ecp-test/index.txt tuser Beim danach erscheinenden Passwort-Prompt das Passwort des (Test-)Users eingeben. Wenn alles funktioniert, wird im Anschluss an allerlei Debug-Output ein „ok“ zurückgegeben. ECP einschränken auf einzelne SPs Aus unserer Sicht ist es nicht nötig, die ECP-Unterstützung auf einzelne SPs einzuschränken. Der Vollständigkeit halber sei hier aber erwähnt, wie das geht: Kommentieren Sie /opt/shibboleth-idp/conf/relying-party.xml im Abschnitt DefaultRelyingParty die Referenz auf das Bean SAML2.ECP aus. Fügen Sie in der Liste der RelyingPartyOverrides eine Konfiguration für diese SPs hinzu. Hier ein Beispiel für bwIDM: /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> idp3, idp4, fixme Zuletzt geändert: vor 4 Jahren Anmelden