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/10/14 16:24] (aktuell) – gelöscht Silke Meyer
@@ Zeile 1: / Zeile 1: @@
-===== Spezielle SP Konfigurationen ======
-==== 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! **
-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:
-<code xml>
-<samlp:AuthnRequest AssertionConsumerServiceURL="https://fsso.springer.com/federation/Consumer/metaAlias/SpringerServiceProvider" ...>
-    <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">https://fsso.springer.com</saml:Issuer>
-    <!-- ... -->
-    <samlp:RequestedAuthnContext Comparison="minimum" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
-        <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified</saml:AuthnContextClassRef>
-    </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/Password" parent="shibboleth.AuthenticationFlow"
-      p:passiveAuthenticationSupported="true"
-      p:forcedAuthenticationSupported="true" />
-</file>
-neu:
-<file xml conf/authn/general-authn.xml>
- <bean id="authn/Password" parent="shibboleth.AuthenticationFlow"
-      p:passiveAuthenticationSupported="true"
-      p:forcedAuthenticationSupported="true" >
-      <property name="supportedPrincipals">
-           <bean parent="shibboleth.SAML2AuthnContextClassRef"
-                c:classRef="urn:oasis:names:tc:SAML:2.0:ac:classes:unspecified" />
-      </property>
- </bean>
-</file>
-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?) ====
-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:
-- WARN [org.opensaml.soap.soap11.decoder.http.impl.HTTPSOAP11Decoder:146] - Saw
-unsupported request Content-Type: text/plain; charset=ISO-8859-1
-- 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!