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
Nächste Überarbeitung Beide Seiten der Revision
de:shibidp3spspecials [2017/03/24 11:18]
Raoul Gunnar Borenius
de:shibidp3spspecials [2019/05/31 09:31]
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-resolver.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 4 Monaten