Dies ist eine alte Version des Dokuments!


Beispiel für eine EU-DSGVO-konforme Konfiguration des User Consent Moduls

Die im folgenden dokumentierte Beispielkonfiguration beruht sowohl auf den Vorschlägen der Forschungsstelle Recht im DFN, "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!

Die im folgenden vorgestellten Beispiele benötigen die hier verlinkte, angepasste Version der messages.properties. Bitte lesen Sie die Inline-Kommentare und passen die Properties den jeweiligen Erfordernissen und Rahmenbedingungen entsprechend an!

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 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 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: terms-of-use.vm sowie für eine statische JSP-Datei, die es EndnutzerInnen erlaubt, auf den aktuellen Wortlaut der Einwilligungserklärung zuzugreifen: 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:

./views/login.vm
<div class="column two">
  <ul class="list list-help">
     <li class="list-help-item"><a href="#springMessageText("idp.url.password.reset", "#")"><span class="item-marker">&rsaquo;</span> #springMessageText("idp.login.forgotPassword", "Forgot your password?")</a></li>
     <li class="list-help-item"><a href="$request.getContextPath()/tou.jsp" target="_blank"><span class="item-marker">&rsaquo;</span> Wortlaut Einwilligungserklärung</a></li>
  </ul>
  <!-- usw. -->

Die Anzeige der Daten sieht dann in etwa so aus:

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: ./views/intercept/attribute-release.vm (Variante 1).

Wenn die Attributfreigabe fallweise aufgrund anderer Erlaubnisnormen erfolgt, bedarf es entsprechend angepasster Interceptor Flows, die je nach anfragendem SP und ggf. Nutzergruppe aufgerufen werden. Siehe hierzu die Lösungsmodelle aus der Präsentation "Datenschutzrechtliche Analyse das AAI-Verfahrens" von der 69. DFN-Betriebstagung und die Präsentation "Wir basteln einen Interceptor Flow".

Neben der angepassten Datei ./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 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 *-bean.xml Dateien die relativen Pfadangaben anpassen:

 <     <import resource="../../conf/audit-system.xml" />
 ---
 >     <import resource="../../../system/conf/audit-system.xml" />

Desgleichen in den *-flow.xml Dateien

 <     <bean-import resource="attribute-release-beans.xml" />
 ---
 >     <bean-import resource="attribute-info-beans.xml" />

bzw.

 <     <bean-import resource="attribute-release-beans.xml" />
 ---
 >     <bean-import resource="attribute-must-beans.xml" />


3. Dafür sorgen, dass Bezeichnung des Events im Log dem jeweils aufgerufenen Flow entspricht (–> Nachweispflichten)

./flows/intercept/attribute-info/attribute-info-flow.xml
     <action-state id="ExtractConsent">
        <evaluate expression="ExtractConsent" />
        <evaluate expression="'AttributeReleaseInfo'" />
 
        <transition on="AttributeReleaseInfo" to="AttributeReleaseInfo" />
    </action-state>
 
    <!-- Write 'AttributeReleaseInfo' event to consent audit log. -->
    <action-state id="AttributeReleaseInfo">
        <evaluate expression="PopulateConsentAuditContext" />
        <evaluate expression="WriteAttributeReleaseConsentAuditLog" />
        <evaluate expression="'proceed'" />
 
        <transition on="proceed" to="TestForDoNotRememberConsent" />
    </action-state>

und

./flows/intercept/attribute-info/attribute-must-flow.xml
     <action-state id="ExtractConsent">
        <evaluate expression="ExtractConsent" />
        <evaluate expression="'AttributeReleaseMust'" />
 
        <transition on="AttributeReleaseMust" to="AttributeReleaseMust" />
    </action-state>
 
    <!-- Write 'AttributeReleaseMust' event to consent audit log. -->
    <action-state id="AttributeReleaseMust">
        <evaluate expression="PopulateConsentAuditContext" />
        <evaluate expression="WriteAttributeReleaseConsentAuditLog" />
        <evaluate expression="'proceed'" />
 
        <transition on="proceed" to="TestForDoNotRememberConsent" />
    </action-state>


4. Neue Flows deklarieren und mit Activation Conditions verknüpfen Dies geschieht am besten in ./conf/intercept/profile-intercept.xml (Beispiel)

  • Zuletzt geändert: vor 9 Monaten