Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung
Vorhergehende Überarbeitung
de:shibidp3spspecials [2017/03/24 11:18]
Raoul Gunnar Borenius
de:shibidp3spspecials [2019/06/03 10:23] (aktuell)
Silke Meyer [Stellenportal von Haufe Umantis]
Zeile 1: Zeile 1:
-===== Spezielle SP Konfigurationen ======+====== Spezielle SP Konfigurationen ​=======
  
-==== 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! ** ** 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! **
Zeile 44: Zeile 44:
 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 ​=====+===== Stellenportal von Haufe Umantis ​===== 
 +Der Anbieter Haufe Umantis bietet lediglich eine Dokumentation für ADFS an. So binden Sie den nicht standardkonformen SP an einen Shibboleth IDP v3 an:
  
-Die Im Moment gängigen BW-Sync&​Share-Clients kommen ​ mit der default-ECP-Variante wie sie der Shibboleth IdP +Legen Sie in der Metadatenverwaltung einen neuen SP an und aktivieren Sie die [[https://​doku.tid.dfn.de/de:metadata_local|lokalen Metadaten]].
-mitbringt leider nicht zurechtDer ECP-Endpunkt muss für diese Clients noch explizit mit Basic-Auth geschützt +
-werdenDies kann mithilfe von Apache oder Tomcat gemacht werden, wobei die Apache variante aus unserer Sicht +
-deutlich simpler ist:+
  
-==== Basic-Auth mithilfe von Apache ====+Definieren Sie ein eigenes Attribut "​umantisAccount":​
  
-ECP-Endpoint per Basic-Auth schützen:​ +<​file ​xml conf/attribute-resolver.xml
- +    <​AttributeDefinition id="​umantisAccount"​ xsi:​type="​Simple">​ 
-<​file ​html /etc/​apache2/​sites-available/​idp.hochschule-XY.de.conf+        <​InputAttributeDefinition ref="​uid" ​/> 
-LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/​certs/​T-TeleSec_GlobalRoot_Class_2.pem +        <DisplayName xml:lang="​en">​Umantis-ID</​DisplayName
-<VirtualHost *:443+        <​DisplayName xml:​lang="​de">​Umantis-ID</​DisplayName>​ 
-  ​ServerName ​             idp.hochschule-XY.de:443 +        <​DisplayDescription xml:​lang="​en">​uid für SP umantis</DisplayDescription
-  ... +        <​DisplayDescription xml:lang="​de"​>uid für SP umantis</​DisplayDescription>​ 
-   +        <​AttributeEncoder xsi:type="​SAML2String"​ name="umantisAccount" ​friendlyName="umantisAccount" /> 
-  # ECP-Config für Sync&​Share-Clients +    </AttributeDefinition>
-  <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>​ </​file>​
  
-Authentifizierung per LDAP im Apache aktivieren:​ +<file xml conf/​attribute-filter.xml
- +  <!-- Bewerberportal Haufe Umantis ​--> 
-<code bash+  <​AttributeFilterPolicy id="​umantis">​ 
-root@idp:~# a2enmod authnz_ldap +    <​PolicyRequirementRule xsi:type="Requester" ​value="http://sso.de.umantis.com/sp-hs_offenburg" ​/> 
-root@idp:~# systemctl reload apache2 +    <AttributeRule attributeID="umantisAccount" ​             ​permitAny="true"/>​ 
-</code> +  </AttributeFilterPolicy>
- +
-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. +
- +
- +
-==== AlternativBasic-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>​ </​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! 
  
  • Zuletzt geändert: vor 3 Jahren