Dies ist eine alte Version des Dokuments!
Spezielle SP Konfigurationen
SpringerLink (https://fsso.springer.com)
Hinweis: Dieses Konfigurationsbeispiel gilt nur für ältere 3er-IdPs. Seit IdP 3.2.0 ist das folgende offenbar nicht mehr nötig bzw. kontraproduktiv!
Dieser SP verwendet in seinen AuthnRequests im RequestedAuthnContext Element den bisher selten verwendeten Comparison-Parameter, womit der IdPv3 in der Basis-Konfiguration bislang nicht umgehen kann:
<samlp:AuthnRequest AssertionConsumerServiceURL="https://fsso.springer.com/federation/Consumer/metaAlias/SpringerServiceProvider" ...> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://fsso.springer.com</saml:Issuer> <!-- ... --> <samlp:RequestedAuthnContext Comparison="minimum" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef> </samlp:RequestedAuthnContext> </samlp:AuthnRequest>
Folgender Workaround wurde von dem Kollegen aus Ilmenau beigesteuert:
alt:
- conf/authn/general-authn.xml
<bean id="authn/Password" parent="shibboleth.AuthenticationFlow" p:passiveAuthenticationSupported="true" p:forcedAuthenticationSupported="true" />
neu:
- conf/authn/general-authn.xml
<bean id="authn/Password" parent="shibboleth.AuthenticationFlow" p:passiveAuthenticationSupported="true" p:forcedAuthenticationSupported="true" > <property name="supportedPrincipals"> <bean parent="shibboleth.SAML2AuthnContextClassRef" c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" /> </property> </bean>
Siehe hierzu auch die 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:
- /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>
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.
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):
- /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>
3. Tomcat den Pfad zur JAAS login.config als Startparameter mitgeben (unter Debian in /etc/default/tomcat8):
- /etc/default/tomcat8
JAVA_OPTS=" ... -Djava.security.auth.login.config=file:/opt/shibboleth-idp/login.config ..."
4. /opt/shibboleth-idp/login.config
ACHTUNG: die Java-Klasse ist eine andere als bei der gewohnten login.config des IdP 2.x !!
- /opt/shibboleth-idp/login.config
ShibUserPassAuth { org.ldaptive.jaas.LdapLoginModule required ldapUrl="..." ssl="true" bindDn="..." bindCredential="..." baseDn="..." userFilter="uid={user}" logCredentials="false" ; };
Power Folder (Sync&Share in Bayern und BW?)
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:
522 - WARN [org.opensaml.soap.soap11.decoder.http.impl.HTTPSOAP11Decoder:146] - Saw unsupported request Content-Type: text/plain; charset=ISO-8859-1 523 - 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!