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
Letzte ÜberarbeitungBeide Seiten der Revision
de:shibidp3spspecials [2017/02/22 09:03] – [SpringerLink (https://fsso.springer.com)] Raoul Gunnar Boreniusde: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/de:metadata_local|lokalen Metadaten]].
  
-** HinweisDieses 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 "umantisAccount":
  
- +<file xml conf/attribute-resolver.xml> 
-Dieser SP verwendet in seinen AuthnRequests im RequestedAuthnContext Element den bisher selten verwendeten Comparison-Parameter, womit der IdPv3 in der Basis-Konfiguration bislang nicht umgehen kann: +    <AttributeDefinition id="umantisAccount" xsi:type="Simple"> 
- +        <InputAttributeDefinition ref="uid" /> 
-<code xml> +        <DisplayName xml:lang="en">Umantis-ID</DisplayName
-<samlp:AuthnRequest AssertionConsumerServiceURL="https://fsso.springer.com/federation/Consumer/metaAlias/SpringerServiceProvider...+        <DisplayName xml:lang="de">Umantis-ID</DisplayName
-    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://fsso.springer.com</saml:Issuer+        <DisplayDescription xml:lang="en">uid für SP umantis</DisplayDescription
-    <!-- ... --> +        <DisplayDescription xml:lang="de">uid für SP umantis</DisplayDescription
-    <samlp:RequestedAuthnContext Comparison="minimum" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> +        <AttributeEncoder xsi:type="SAML2Stringname="umantisAccountfriendlyName="umantisAccount/> 
-        <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef+    </AttributeDefinition>
-    </samlp:RequestedAuthnContext> +
-</samlp:AuthnRequest+
- +
-</code +
- +
-Folgender Workaround wurde von dem Kollegen aus Ilmenau beigesteuert:   +
- +
-alt: +
- +
-<file xml conf/authn/general-authn.xml+
- <bean id="authn/Passwordparent="shibboleth.AuthenticationFlow" +
-      p:passiveAuthenticationSupported="true+
-      p:forcedAuthenticationSupported="true" />+
 </file> </file>
  
-neu: +<file xml conf/attribute-filter.xml> 
- +  <!-- Bewerberportal Haufe Umantis --> 
-<file xml conf/authn/general-authn.xml> +  <AttributeFilterPolicy id="umantis"> 
- <bean id="authn/Password" parent="shibboleth.AuthenticationFlow+    <PolicyRequirementRule xsi:type="Requestervalue="http://sso.de.umantis.com/sp-hs_offenburg/
-      p:passiveAuthenticationSupported="true" +    <AttributeRule attributeID="umantisAccount             permitAny="true"/> 
-      p:forcedAuthenticationSupported="true" > +  </AttributeFilterPolicy>
-      <property name="supportedPrincipals"+
-           <bean parent="shibboleth.SAML2AuthnContextClassRef" +
-                c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" /> +
-      </property+
- </bean>+
 </file> </file>
  
-Siehe hierzu auch die Dokumentation im [[https://wiki.shibboleth.net/confluence/display/IDP30/AuthenticationFlowSelection#AuthenticationFlowSelection-ComparisonConfiguration|Shibboleth Wiki]] +{{tag>idp3 FIXME}}
- +
-==== Power Folder (Sync&Share in Bayern und BW?) ==== +
- +
-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! +