Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Nächste Überarbeitung		 Vorhergehende Überarbeitung
Nächste ÜberarbeitungBeide Seiten der Revision
de:shibidp3spspecials [2015/10/23 18:06] – angelegt Wolfgang Pempede:shibidp3spspecials [2017/03/24 11:18] – Raoul Gunnar Borenius
Zeile 2: Zeile 2:
  
 ==== SpringerLink (https://fsso.springer.com) ==== ==== 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: 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:
Zeile 40: Zeile 43:
  
 Siehe hierzu auch die Dokumentation im [[https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection#AuthenticationFlowSelection-ComparisonConfiguration|Shibboleth Wiki]] Siehe hierzu auch die Dokumentation im [[https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection#AuthenticationFlowSelection-ComparisonConfiguration|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:
 +
 +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!