Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:shibidp3spspecials [2017/03/24 11:18] – Raoul Gunnar Borenius | de:shibidp3spspecials [2019/05/31 09:29] – Silke Meyer | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ===== Spezielle SP Konfigurationen ====== | + | ====== Spezielle SP Konfigurationen |
- | ==== SpringerLink (https:// | + | ===== SpringerLink (https:// |
** 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:// | Siehe hierzu auch die Dokumentation im [[https:// | ||
- | ===== ECP für BWSync& | + | ===== 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& | + | Legen Sie in der Metadatenverwaltung einen neuen SP an und aktivieren Sie die [https:// |
- | 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 ==== | + | Definieren Sie ein eigenes Attribut " |
- | ECP-Endpoint per Basic-Auth schützen: | + | < |
- | + | < | |
- | < | + | < |
- | LDAPTrustedGlobalCert CA_BASE64 /etc/ssl/ | + | <DisplayName xml:lang=" |
- | <VirtualHost *:443> | + | < |
- | | + | < |
- | ... | + | < |
- | + | < | |
- | # ECP-Config für Sync& | + | </AttributeDefinition> |
- | <Location | + | |
- | | + | |
- | AuthName | + | |
- | | + | |
- | AuthLDAPURL "ldaps:// | + | |
- | AuthLDAPBindDN | + | |
- | AuthLDAPBindPassword | + | |
- | Require valid-user | + | |
- | </Location> | + | |
- | </VirtualHost> | + | |
</ | </ | ||
- | Authentifizierung per LDAP im Apache aktivieren: | + | <file xml conf/attribute-resolver.xml> |
- | + | <!-- Bewerberportal Haufe Umantis | |
- | <code bash> | + | < |
- | root@idp:~# a2enmod authnz_ldap | + | < |
- | root@idp:~# systemctl reload apache2 | + | <AttributeRule attributeID="umantisAccount" |
- | </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. | + | |
- | + | ||
- | + | ||
- | ==== Alternativ: Basic-Auth mithilfe von Tomcat | + | |
- | + | ||
- | **1. web.xml** (unter /edit-webapp/WEB-INF bearbeiten): | + | |
- | Die beiden Blöcke am Ende ent-kommentieren: | + | |
- | authentication" | + | |
- | + | ||
- | **2. Context Fragment in Tomcat-Konfiguration anpassen.** \\ | + | |
- | Das sieht dann ungefähr so aus (appName, Pfade etc. ggf. anpassen): | + | |
- | + | ||
- | <file xml /etc/tomcat8/ | + | |
- | <Context docBase=" | + | |
- | | + | |
- | | + | |
- | | + | |
- | | + | |
- | <Realm className="org.apache.catalina.realm.JAASRealm" | + | |
- | </Context> | + | |
</ | </ | ||
- | |||
- | **3. Tomcat den Pfad zur JAAS login.config als Startparameter mitgeben** (unter Debian in | ||
- | / | ||
- | |||
- | <file bash / | ||
- | JAVA_OPTS=" | ||
- | ..." | ||
- | </ | ||
- | |||
- | **4. / | ||
- | |||
- | ** ACHTUNG: die Java-Klasse ist eine andere als bei der gewohnten login.config des IdP 2.x !!** | ||
- | |||
- | <file javascript / | ||
- | ShibUserPassAuth { | ||
- | | ||
- | ldapUrl=" | ||
- | ssl=" | ||
- | bindDn=" | ||
- | bindCredential=" | ||
- | baseDn=" | ||
- | userFilter=" | ||
- | logCredentials=" | ||
- | ; | ||
- | }; | ||
- | </ | ||
- | |||
- | |||
- | ==== Probleme mit Sync& | ||
- | |||
- | Aus Bayern haben wir Probleme mit dem Zugriff auf den bayerischen Sync& | ||
- | 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: | ||
- | unsupported request Content-Type: | ||
- | 523 - ERROR [org.opensaml.profile.action.impl.DecodeMessage: | ||
- | DecodeMessage: | ||
- | org.opensaml.messaging.decoder.MessageDecodingException: | ||
- | charset=ISO-8859-1' | ||
- | org.opensaml.soap.soap11.decoder.http.impl.HTTPSOAP11Decoder.validateHttpRequest(HTTPSOAP11Decoder.j | ||
- | ava:147 | ||
- | |||
- | |||
- | Problem ist die " | ||
- | Content-Type-Prüfung durchgeführt, | ||
- | |||
- | Man kann entweder wieder auf IdP 3.2.x zurückgehen oder als Workaround die " | ||
- | opensaml-soap-impl-3.3.0.jar (unter ../ | ||
- | opensaml-soap-impl-3.2.0.jar (welche im " | ||
- | ../ | ||
- | einen ./build.sh durchführen und die Anmeldung sollte wieder funktionieren. Dieser | ||
- | Workaround ist natürlich auf eigene Gefahr! | ||