Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp3storage [2017/09/07 08:50] – [Weitergabe der Persistent ID] Raoul Gunnar Borenius
+++ de:shibidp3storage [2019/01/21 11:32] – Wolfgang Pempe
@@ Zeile 1: / Zeile 1: @@
-====== Server-Side-Storage und Persistent Identifier ======
+====== Server-Side-Storage, Sessions, User Consent und Persistent Identifier ======
-Per default werden Informationen zu User Consent (ehemals uApprove) und Persistent IDs client-seitig in Cookies abgelegt. Dies kann aber nur als initiale "Notlösung" betrachtet werden, damit der IdP auch ohne angeschlossene SQL-Datenbank funktioniert. In einem fertigen Produktivszenario ist das Abspeichern dieser Informationen auf Serverseite unbedingt zu empfehlen, da nur damit erweiterte SAML-Funktionalitäten möglich sind (z.B. persistentId,
+Per default werden Informationen zu Sessions, User Consent (insbesondere bzgl. Attributfreigabe) und Persistent IDs client-seitig in Cookies abgelegt. Dies kann aber nur als initiale "Notlösung" betrachtet werden, damit der IdP auch ohne angeschlossene SQL-Datenbank funktioniert. In einem fertigen Produktivszenario ist das Abspeichern dieser Informationen auf Serverseite unbedingt zu empfehlen, da nur damit erweiterte SAML-Funktionalitäten möglich sind (z.B. persistentId, Single-Logout).
-Single-Logout).
+**Darüber hinaus kann nur auf diese Weise sichergestellt werden, dass bei Attribute Queries (SP fragt anhand eines Name Identifiers direkt beim IdP Nutzerdaten ab), die Entscheidungen des/der Nutzers/Nutzerin hinsichtlich Attributfreigabe berücksichtigt werden!**
 ===== Installation Datenbanksoftware =====
@@ Zeile 173: / Zeile 174: @@
 Damit werden die Usernamen vom IdP nur noch in Kleinbuchstabenform verarbeitet und in die Datenbank geschrieben.
-===== Session-Informationen und User Consent in DB ablegen =====
+===== Session-Informationen und User Consent =====
-Nachdem Datenbankverbindung und persistentId aktiviert sind, können diese nun für die Speicherung von Session- und User Consent-Informationen genutzt werden. Dadurch wird als netter Nebeneffekt auch SingleLogout-
+Nachdem Datenbankverbindung und persistentId aktiviert sind, können diese nun für die Speicherung von Session- und User Consent-Informationen genutzt werden. Dadurch wird als netter Nebeneffekt auch [[de:shibidp3slo|SingleLogout-Unterstützung]] im IdP ermöglicht. Außerdem können nun bei Attribute Queries Nutzer-Entscheidungen zu Attributfreigaben berücksichtigt werden (siehe unten).
-Unterstützung im IdP ermöglicht:
 <file properties /opt/shibboleth-idp/conf/idp.properties>
@@ Zeile 188: / Zeile 188: @@
 # Set to "shibboleth.consent.AttributeConsentStorageKey" to use an attribute
 # to key user consent storage records (and set the attribute name)
-idp.consent.userStorageKey = shibboleth.consent.AttributeConsentStorageKey
+idp.consent.attribute-release.userStorageKey = shibboleth.consent.PrincipalConsentStorageKey
-idp.consent.userStorageKeyAttribute = %{idp.persistentId.sourceAttribute}
+idp.consent.attribute-release.userStorageKeyAttribute = %{idp.persistentId.sourceAttribute}
+idp.consent.terms-of-use.userStorageKey = shibboleth.consent.PrincipalConsentStorageKey
+idp.consent.terms-of-use.userStorageKeyAttribute = %{idp.persistentId.sourceAttribute}
 # Flags controlling how built-in attribute consent feature operates
@@ Zeile 202: / Zeile 204: @@
 # Verfügung steht sollte dieses sinnvolle Feature aktiviert werden!
 idp.consent.compareValues = true
+</file>
+===== User Consent zu Attributfreigabe bei Attribute Queries berücksichtigen =====
+Damit bei Attribute Queries Nutzer-Entscheidungen zur Attributfreigabe berücksichtigt werden, muss in ./conf/intercept/consent-intercept-config.xml die entsprechende Condition gesetzt werden:
+<file xml ./conf/intercept/consent-intercept-config.xml>
+    <!--
+    Condition to evaluate to apply attribute-release consent to attribute queries.
+    -->
+    <bean id="shibboleth.consent.AttributeQuery.Condition" parent="shibboleth.Conditions.TRUE" />
 </file>
@@ Zeile 210: / Zeile 223: @@
 ===== Weitergabe der Persistent ID =====
-Um in den Fällen, in denen ein anfragender SP keine Präferenzen bzgl. Name ID Format signalisiert (Metadaten und/oder AuthnRequest), eine Gewichtung festzulegen, kann die SAML2.SSO-Bean-Definition entsprechend erweitert werden:
+Um in den Fällen, in denen ein anfragender SP keine Präferenzen bzgl. Name ID Format signalisiert (Metadaten und/oder AuthnRequest), eine Gewichtung festzulegen (siehe hierzu die [[https://wiki.shibboleth.net/confluence/display/IDP30/NameIDGenerationConfiguration#NameIDGenerationConfiguration-FormatSelectionFormatSelection|Doku im Shibboleth-Wiki]]), kann die SAML2.SSO-Bean-Definition **bei Bedarf** entsprechend erweitert werden:
 <file xml /conf/relying-party.xml>
@@ Zeile 238: / Zeile 251: @@
 persistentId übertragen wird.
-HINWEIS: Da die persistendId kein SAML-Attribut ist wird Ihnen diese nach dem Login am IdP nicht in der Liste der zu übertragenden Attribute angezeigt. Erst wenn Sie wieder am Test-SP sind wird Ihnen dort die persistentId, sofern diese übertragen wurde, zusammen mit den übertragenen Attributen angezeigt.
+HINWEIS: Da die persistendId kein SAML-Attribut ist, wird Ihnen diese nach dem Login am IdP nicht in der Liste der zu übertragenden Attribute angezeigt. Erst wenn Sie wieder am Test-SP sind wird Ihnen dort die persistentId, sofern diese übertragen wurde, zusammen mit den übertragenen Attributen angezeigt.
-Falls Sie die persistentId nur an ausgewählte SPs übertragen wollen, finden Sie Beispiele unter [[de:shibidp3pidspecials|Persistent ID - Sonderfälle]].
+Falls die persistentId nur an ausgewählte SPs übertragen werden soll, so finden sich [[[[de:shibidp3pidspecials|hier einige Beispiele]].
 ** Weiter geht es mit [[de:shibidp3slo|Single Logout]]. **