Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp3spspecials [2017/02/22 09:03] – [SpringerLink (https://fsso.springer.com)] Raoul Gunnar Borenius
+++ de:shibidp3spspecials [2020/04/16 09:05] – Silke Meyer
@@ 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! **
@@ Zeile 45: / Zeile 44: @@
 Siehe hierzu auch die Dokumentation im [[https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection#AuthenticationFlowSelection-ComparisonConfiguration|Shibboleth Wiki]]
-==== Power Folder (Sync&Share in Bayern und BW?) ====
+===== 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:
-Aus Bayern haben wir Probleme mit dem Zugriff auf den bayerischen Sync&Share-Dienst nach Upgrade
+Legen Sie in der Metadatenverwaltung einen neuen SP an und aktivieren Sie die [[https://doku.tid.dfn.de/de:metadata_local|lokalen Metadaten]].
-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
+Definieren Sie ein eigenes Attribut "umantisAccount":
-bei dem Fehler folgende Einträge:
- - WARN [org.opensaml.soap.soap11.decoder.http.impl.HTTPSOAP11Decoder:146] - Saw
+<file xml conf/attribute-resolver.xml>
-unsupported request Content-Type: text/plain; charset=ISO-8859-1
+    <AttributeDefinition id="umantisAccount" xsi:type="Simple">
-- ERROR [org.opensaml.profile.action.impl.DecodeMessage:73] - Profile Action
+        <InputAttributeDefinition ref="uid" />
-DecodeMessage: Unable to decode incoming request
+        <DisplayName xml:lang="en">Umantis-ID</DisplayName>
-org.opensaml.messaging.decoder.MessageDecodingException: Content-Type 'text/plain;
+        <DisplayName xml:lang="de">Umantis-ID</DisplayName>
-charset=ISO-8859-1' was not a supported media type at
+        <DisplayDescription xml:lang="en">uid für SP umantis</DisplayDescription>
-org.opensaml.soap.soap11.decoder.http.impl.HTTPSOAP11Decoder.validateHttpRequest(HTTPSOAP11Decoder.j
+        <DisplayDescription xml:lang="de">uid für SP umantis</DisplayDescription>
-ava:147
+        <AttributeEncoder xsi:type="SAML2String" name="umantisAccount" friendlyName="umantisAccount" />
+    </AttributeDefinition>
+</file>
+<file xml conf/attribute-filter.xml>
+  <!-- Bewerberportal Haufe Umantis -->
+  <AttributeFilterPolicy id="umantis">
+    <PolicyRequirementRule xsi:type="Requester" value="http://sso.de.umantis.com/sp-hs_offenburg" />
+    <AttributeRule attributeID="umantisAccount"              permitAny="true"/>
+  </AttributeFilterPolicy>
+</file>
-Problem ist die "Klasse" opensaml-soap-impl-3.3.0.jar. In dieser wird neuerdings eine
+{{tag>idp3 FIXME}}
-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!