====== Beispiel für eine EU-DSGVO-konforme Konfiguration des User Consent Moduls ====== Mit dem Wegfall sowohl des ./system Verzeichnisses als auch der damit verbundenen Verfügbarkeit der entsprechenden *-bean.xml und *-flow.xml Dateien in Version 4.1.x muss die Umsetzung grundlegend anders erfolgen. Siehe hierzu [[de:shibidp:config-consent-dsgvo|diese Seite]]. Bei Shib IdP Version 4 haben sich Details an den Standard-Flows geändert. Wir empfehlen daher, nach dem Upgrade auf Version 4.x die unten beschriebenen Flows unter ./flows/intercept neu anzulegen und die entsprechenden Anpassungen vorzunehmen. Die im folgenden dokumentierte Beispielkonfiguration beruht sowohl auf den Vorschlägen der Forschungsstelle Recht im DFN, [[https://download.aai.dfn.de/praesentationen/betriebstagungen/69/BT69_AAI_DS-AAI-Verfahren_Strobel_Moerike.pdf|"Datenschutzrechtliche Analyse das AAI-Verfahrens", 69. BT]] als auch auf hausinternen Konsultationen mit dem Justiziariat des DFN-Vereins. **Beachten Sie bitte, dass es sich hierbei um unverbindliche Vorschläge handelt! Der DFN-Verein übernimmt keine Verantwortung für etwaige juristische Streitfälle, die sich aus diesen Beispielen oder daraus abgeleiteten Konfigurationen ergeben!** ==== Vorarbeiten ==== Führen Sie zunächst die unter [[de:shibidp:config-tou#aktivierung_der_nutzungsbedingungen|Aktivierung der Nutzungsbedingungen]] beschrieben Arbeitsschritte durch. ==== Message Properties ==== Die im folgenden vorgestellten Beispiele benötigen die hier verlinkte, angepasste Version der **[[de:shibidp:config-consent-dsgvo-messages|messages.properties]]**. Bitte lesen Sie die Inline-Kommentare und passen die Properties den jeweiligen Erfordernissen und Rahmenbedingungen entsprechend an! ==== Terms of Use ==== Unabhängig davon, auf welcher Rechtsgrundlage die Übertragung von Attributen an einen Service Provider erfolgt, kann der **Terms-of-Use Consent** unter anderem dazu verwendet werden, eine Einwilligung in die Generierung und Speicherung der [[de:shibidp:config-storage|SAML2 Persistent Name ID]] (Persistent Id) einzuholen. Dies ist insofern sinnvoll, als es sich bei bei der Persistent Id um kein Attribut handelt und Endnutzer beim Zugriff auf einen SP nicht steuern können, ob eine Persistent Id übertragen wird. Die Übertragung der Persistent Id wird per Default zwischen IdP und SP ausgehandelt und kann ggf. seitens des IdP-Admins durch eine entsprechend angepasste Relying Party Konfiguration gesteuert werden. Siehe hierzu unter [[de:shibidp:config-storage#weitergabe_der_persistent_id|Weitergabe der Persistent Id]]. Unser Beispiel stellt noch eine allgemeine Funktionsbeschreibung des IdP voran. Konkret handelt es sich um die Properties ''my-service-description'' und ''my-tou.text''. Selbstverständlich kann (und soll) dieser Text durch weitere, für die jeweilige Einrichtung relevante Punkte ergänzt werden. Hier ein Beispiel für ein Velocity Template, das diese Properties zum Einholen der Einwilligung der EndnutzerInnen anzeigt: **[[de:shibidp:config-consent-dsgvo-tou|terms-of-use.vm]]** sowie für eine statische JSP-Datei, die es EndnutzerInnen erlaubt, auf den aktuellen Wortlaut der Einwilligungserklärung zuzugreifen: **[[de:shibidp:config-consent-dsgvo-tou-jsp|tou.jsp]]**. Die letztgenannte Datei muss unter ''./edit-webapp'' abgelegt werden. Änderungen an dieser Datei erfordern daher eine erneute Generierung des IdP-Servlets via ''./bin/build.sh'' (bzw. ''./bin/build.bat''). Diese Datei (tou.jsp) kann an beliebiger Stelle verlinkt werden, z.B. im Footer und/oder auf der Login-Seite des IdP:
Die Anzeige der Daten sieht dann in etwa so aus: \\ {{:de:tou.png?200|}} ==== Attribute Release ==== **Sofern die Übertragung von Attributen ausschließlich freiwillig, aufgrund einer Einwilligung der EndnutzerInnen erfolgt (DSGVO Art. 6.1 lit a), muss kein separater Flow definiert werden!** Hier ein Beispiel für ein entsprechendes Velocity Template: **[[de:shibidp:config-consent-dsgvo-attribute-release|./views/intercept/attribute-release.vm]] (Variante 1)**. \\ {{:de:01_user_consent.png?200|}} ==== Attribute Release aufgrund unterschiedlicher Rechtsgrundlagen ==== Wenn die Attributfreigabe fallweise aufgrund anderer Erlaubnisnormen erfolgt, bedarf es entsprechend angepasster [[https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631714/ProfileInterceptConfiguration|Interceptor Flows]], die je nach anfragendem SP und ggf. Nutzergruppe aufgerufen werden. Siehe hierzu die Lösungsmodelle aus der Präsentation [[https://download.aai.dfn.de/praesentationen/betriebstagungen/69/BT69_AAI_DS-AAI-Verfahren_Strobel_Moerike.pdf|"Datenschutzrechtliche Analyse das AAI-Verfahrens"]] von der 69. DFN-Betriebstagung und die Präsentation [[https://download.aai.dfn.de/ws/2018_fub/interceptor_dsgvo.pdf|"Wir basteln einen Interceptor Flow"]]. Neben der angepassten Datei **[[de:shibidp:config-consent-dsgvo-attribute-release|./views/intercept/attribute-release.vm]]** (siehe oben) werden hierfür noch die Velocity Templates **attribute-info.vm** und **attribute-must.vm**, die von der selben **[[de:shibidp:config-consent-dsgvo-attribute-release|Wiki Seite]]** heruntergeladen werden können (Varianten 2 und 3) und die ebenfalls in ''./views/intercept'' abgelegt werden. Weiterhin sind folgende Konfigurationsschritte erforderlich: \\ **1. Flow aus bestehendem Interceptor erstellen:** .''/system/flows/intercept/attribute-release-beans.xml'' und \\ ''./system/flows/intercept/attribute-release-flow.xml'' \\ jeweils kopieren nach: \\ ''./flows/intercept/attribute-info/attribute-info-beans.xml'' \\ ''./flows/intercept/attribute-info/attribute-info-flow.xml'' \\ und \\ ''./flows/intercept/attribute-must/attribute-must-beans.xml'' \\ ''./flows/intercept/attribute-must/attribute-must-flow.xml'' \\ **2. In den kopierten Dateien die Pfade anpassen:** In den *-flow.xml Dateien die Referenzen auf die bean-Dateien anpassen: < --- > bzw. < --- > \\ **3. Dafür sorgen, dass Bezeichnung des Events im Log dem jeweils aufgerufenen Flow entspricht (--> Nachweispflichten)** und \\ **4. Neue Flows deklarieren und mit Activation Conditions verknüpfen** Dies geschieht am besten in **[[de:shibidp:config-consent-dsgvo-profile-intercept|./conf/intercept/profile-intercept.xml (Beispiel)]]** \\ **5. Neue Flows in der Relying Party Konfiguration dem SSO-Profil als Post Authentication Flows zuordnen** \\ **HTML-Ansicht ''attribute-info.vm''**\\ {{:de:02_user_consent.png?200|}} **HTML-Ansicht ''attribute-must.vm''**\\ {{:de:03_user_consent.png?200|}} ==== Attribute Query und User Consent ==== Bei Attribute Queries kann die jeweils letzte Entscheidung des Users zur Attributfreigabe berücksichtigt werden. Dies funktioniert natürlich nur, wenn die (virtuellen) Entscheidungen zur Attributfreigabe in einer IdP-seitigen Datenbank abgelegt werden und eine entsprechende Condition gesetzt ist. Siehe hierzu unter [[de:shibidp:config-storage#user_consent_zu_attributfreigabe_bei_attribute_queries_beruecksichtigen|Server-Side-Storage - User Consent]]. Damit Attribute Queries unter diesen Rahmenbedingungen auch im oben skizzierten Setup funktionieren, sind weitere Konfigurationsschritte erforderlich: Zunächst die Dateien \\ ''./system/flows/intercept/attribute-release-query-beans.xml'' und \\ ''./system/flows/intercept/attribute-release-query-flow.xml'' \\ in ein Verzeichnis namens \\ ''./flows/intercept/attribute-release-query'' \\ kopieren. Anschließend müssen diverse Anpassungen vorgenommen werden: In der Flow-Definition den Block nach '''' anpassen und erweitern: Anschließend noch den flow in ''./conf/intercept/profile-intercept.xml'' bekannt machen: {{tag>idp4 fixme}}