Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp3storage [2017/03/24 16:56] – [PersistentId Konfiguration] 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 39: / Zeile 40: @@
 ===== Datenbank-Konfiguration =====
-Zunächst ist eine logische Datenbank zu erstellen. Hierzu müssen, wie vom IdP 2.x gewohnt, zunächst nur die Tabellen für die Angaben zur Persistent Id angelegt werden, die Tabelle "StorageRecords" (u.a. für die User Consent Informationen) wird automatisch generiert.
+Zunächst ist eine logische Datenbank zu erstellen. Hierzu müssen, wie vom IdP 2.x gewohnt, zunächst nur die Tabellen für die Angaben zur Persistent Id angelegt werden, die Tabelle "StorageRecords" (u.a. für die User Consent Informationen) wird automatisch generiert (zumindest bei Verwendung von MySQL, wir haben von einem Teilnehmer die Rückemldung dass diese Tabelle unter MS-SQL von Hand angelegt werden musste).
 Hier ein Beispiel für MySQL, wobei hier vorausschauend auch gleich eine Tabelle für die persistentId angelegt wird, welche später noch gebraucht wird (siehe später in dieser Anleitung):
@@ Zeile 73: / Zeile 74: @@
 Der DB-Zugriff wird über den [[https://wiki.shibboleth.net/confluence/display/IDP30/StorageConfiguration|JPAStorageService]] gekapselt. Dieser wird in ./conf/global.xml definiert.
 Diese Datei ist im Auslieferungszustand leer (bis auf Kommentare). Ersetzen Sie sie durch die [[de:global_xml-example|hier bereitgestellte Version]].
-Starten Sie Tomcat neu, um sicherzustellen, dass die global.xml ohne Probleme eingelesen werden kann (dabei Logdateien mitverfolgen!):
-<code bash>
-root@idp:/opt/shibboleth-idp# service tomcat8 restart
-</code>
-Hinweis: bei älteren Java Versionen führt der Parameter "p:validationQueryTimeout" zu einer Fehlermeldung, in dem Fall einfach weglassen und Tomcat neu starten.
@@ Zeile 96: / Zeile 90: @@
 mysql.password = GeHEIM007
 </file>
-Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):
+Starten Sie Tomcat neu, um sicherzustellen, dass die global.xml ohne Probleme eingelesen werden kann (dabei Logdateien mitverfolgen!):
 <code bash>
 root@idp:/opt/shibboleth-idp# service tomcat8 restart
 </code>
+Hinweis: bei älteren Java Versionen führt der Parameter "p:validationQueryTimeout" zu einer Fehlermeldung, in dem Fall einfach weglassen und Tomcat neu starten.
 ===== PersistentId Konfiguration =====
@@ Zeile 166: / Zeile 164: @@
 </file>
-Viertens: meist sind Usernamen unabhängig von Gross- und Kleinschreibung. D.h. die User können Ihren Loginnamen
+Viertens: meist sind Usernamen im IdM-System unabhängig von Gross- und Kleinschreibung. D.h. die User können Ihren Loginnamen sowohl in Gross- als auch Kleinschreibung angeben und damit einen erfolgreichen Login durchführen. Allerdings führt dieses später zu Problemen beim Verwalten der Usernamen in der lokalen IdP-Datenbank da diese Gross- und Kleinschreibung unterscheidet. Wir empfehlen daher den Usernamen in diesen Fällen im IdP in Kleinbuchstaben umzuwandeln:
-sowohl in Gross- als auch Kleinschreibung angeben und damit einen erfolgreichen Login durchführen. Allerdings
-führt dieses später zu Problemen wenn der Username in der Datenbank abgelegt wird. Wir empfehlen daher den
-Usernamen im IdP in Kleinbuchstaben umzuwandeln:
 <file xml ./conf/c14n/simple-subject-c14n-config.xml>
@@ Zeile 177: / Zeile 172: @@
 </file>
-Damit werden die Usernamen nur noch in Kleinbuchstaben im IdP verarbeitet und in die Datenbank geschrieben.
+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 194: / 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 208: / 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 216: / Zeile 223: @@
 ===== Weitergabe der Persistent ID =====
-Um die persistentId für alle SPs freizugeben muss die SAML2.SSO-Bean-Definition 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 244: / Zeile 251: @@
 persistentId übertragen wird.
-Falls Sie die persistentId nur an ausgewählte SPs übertragen wollen, finden Sie Beispiele unter [[de:shibidp3pidspecials|Persistent ID - Sonderfälle]].
+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 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]]. **