Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
de:shibidp3spspecials [2017/02/22 09:03] – [SpringerLink (https://fsso.springer.com)] Raoul Gunnar Borenius | de:shibidp3spspecials [2020/10/14 16:21] – Silke Meyer | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ===== Spezielle SP Konfigurationen ====== | + | ====== Spezielle SP Konfigurationen |
+ | ===== 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: | ||
- | ==== SpringerLink (https://fsso.springer.com) ==== | + | Legen Sie in der Metadatenverwaltung einen neuen SP an und aktivieren Sie die [[https://doku.tid.dfn.de/ |
- | ** 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! ** | + | Definieren Sie ein eigenes Attribut " |
- | + | <file xml conf/ | |
- | Dieser SP verwendet in seinen AuthnRequests im RequestedAuthnContext Element den bisher selten verwendeten Comparison-Parameter, | + | <AttributeDefinition id="umantisAccount" |
- | + | <InputAttributeDefinition ref="uid" /> | |
- | <code xml> | + | <DisplayName xml:lang="en"> |
- | <samlp: | + | <DisplayName xml:lang="de">Umantis-ID</DisplayName> |
- | <saml:Issuer xmlns:saml="urn: | + | <DisplayDescription xml:lang=" |
- | <!-- ... --> | + | <DisplayDescription xml: |
- | <samlp:RequestedAuthnContext Comparison="minimum" | + | <AttributeEncoder xsi:type="SAML2String" |
- | <saml:AuthnContextClassRef xmlns:saml="urn: | + | </AttributeDefinition> |
- | </samlp:RequestedAuthnContext> | + | |
- | </samlp: | + | |
- | + | ||
- | </code> | + | |
- | + | ||
- | Folgender Workaround wurde von dem Kollegen aus Ilmenau beigesteuert: | + | |
- | + | ||
- | alt: | + | |
- | + | ||
- | <file xml conf/authn/ | + | |
- | <bean id="authn/ | + | |
- | p: | + | |
- | | + | |
</ | </ | ||
- | neu: | + | <file xml conf/attribute-filter.xml> |
- | + | <!-- Bewerberportal Haufe Umantis --> | |
- | <file xml conf/authn/ | + | < |
- | <bean id="authn/ | + | < |
- | p:passiveAuthenticationSupported="true" | + | <AttributeRule attributeID="umantisAccount" |
- | p: | + | </AttributeFilterPolicy> |
- | <property name="supportedPrincipals"> | + | |
- | < | + | |
- | c: | + | |
- | </property> | + | |
- | </bean> | + | |
</ | </ | ||
- | Siehe hierzu auch die Dokumentation im [[https:// | + | {{tag> |
- | + | ||
- | ==== Power Folder (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! | + |