Mit der folgenden Konfiguration erreichen Sie, dass die Nutzer*innen bei der erstmaligen Anmeldung über den IdP und bei Änderungen an den Nutzungsbedingungen informiert und um Zustimmung gebeten werden. Die Nutzungsbedingungen aktivieren Sie in folgenden Schritten:

Ab dem IdP 4.1.0 müssen Sie zunächst das Intercept Consent-Modul aktivieren, damit Sie die erste Datei überhaupt haben. Dieser Schritt ist bis IdP 4.0.1 nicht nötig.

bin/module.sh -t idp.intercept.Consent || bin/module.sh -e idp.intercept.Consent

Dann modifizieren Sie die Datei ./conf/intercept/consent-intercept-config.xml:

Vor IdP 4.1.0:

./conf/intercept/consent-intercept-config.xml

 ...
    <!--
    Terms of use is driven by a lookup function returning a key into messages/consent-messages.properties
 
    The default mapping returns the relying party / SP name as the key. The second example below
    demonstrates use of a custom mapping table from the relying party name to the key to use.
    -->
 
    <!-- Diesen alias-Block deaktivieren, damit das folgende bean aktiv werden kann -->
    <!-- <alias alias="shibboleth.consent.terms-of-use.Key" name="shibboleth.RelyingPartyIdLookup.Simple" /> -->
 
    <!-- bean einfügen, das die statischen Terms-Of-Use aus consent-messages.properties referenziert -->
    <bean id="shibboleth.consent.terms-of-use.Key" class="com.google.common.base.Functions" factory-method="constant">
        <constructor-arg value="my-terms"/>
    </bean>
 
    <!-- ...

Ab IdP 4.1.0:

./conf/intercept/consent-intercept-config.xml

 ...
    <!--
    Terms of use is driven by a lookup function returning a key into messages/consent-messages.properties
 
    The default mapping returns the relying party / SP name as the key. The second example below
    demonstrates use of a custom mapping table from the relying party name to the key to use.
    -->
 
    <!-- bean einfügen, das die statischen Terms-Of-Use aus consent-messages.properties referenziert -->
    <bean id="shibboleth.consent.terms-of-use.Key" class="com.google.common.base.Functions" factory-method="constant">
        <constructor-arg value="my-terms"/>
    </bean>
 
    <!-- ...

Zweitens modifizieren Sie das SAML2.SSO-Profil in ./conf/relying-party.xml. Das SAML1-Profil Shibboleth.SSO wird nicht mehr benötigt. Falls Sie auf die Idee kommen, es einzukommentieren, muss dort dieselbe Änderung gemacht machen, wie hier im Beispiel:

./conf/relying-party.xml

    <!-- Default configuration, with default settings applied for all profiles. -->
    <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
        <property name="profileConfigurations">
            <list>
                <!-- SAML 1.1 and SAML 2.0 AttributeQuery are disabled by default. -->
                <!--
                <bean parent="Shibboleth.SSO" p:postAuthenticationFlows="#{ {'terms-of-use', 'attribute-release'} }"/>
                <ref bean="SAML1.AttributeQuery" />
                <ref bean="SAML1.ArtifactResolution" />
                -->
                <!-- SAML2.SSO Standard-Zeile erweitern: -->
                <bean parent="SAML2.SSO" p:postAuthenticationFlows="#{ {'terms-of-use', 'attribute-release'} }" />
                <ref bean="SAML2.ECP" />
                <ref bean="SAML2.Logout" />
                <!--
                <ref bean="SAML2.AttributeQuery" />
                -->
                <ref bean="SAML2.ArtifactResolution" />
                <ref bean="Liberty.SSOS" />
            </list>
        </property>
    </bean>                       

Starten Sie Tomcat neu:

root@idp:~# systemctl restart tomcat9

Den eigentlichen Text der Nutzungsbedingungen konfigurieren Sie in ./messages/messages.properties bzw. ./messages/messages_de.properties:

./messages/messages.properties

my-terms     = my-tou
my-tou.title = Example Terms of Use
my-tou.text  = This is an example Terms of Use

Nach Änderungen im messages-Ordner müssen Sie die Datei ./war/idp.war erneuern lassen: ./bin/build.sh

Um die Nutzungsbedingungen auch nach dem ersten Mal noch einsehen zu können, kann ein entsprechender Link im Footer der IdP-Seiten mitgeführt werden. Damit dieser Link funktioniert, legen Sie bitte folgende Datei an:

./edit-webapp/tou.jsp

<%@ page pageEncoding="UTF-8" %>
<%@ taglib uri="http://www.springframework.org/tags" prefix="spring" %>
<!DOCTYPE html>
<html>
 <head>
  <meta charset="utf-8">
  <title>
   <spring:message code="root.title" text="Shibboleth IdP" /> - <spring:message code="my-tou.title" text="Terms of Use" />
  </title>
  <link rel="stylesheet" type="text/css" href="<%= request.getContextPath()%>/css/consent.css">
 </head>
 
 <body>
  <div class="box">
   <header>
    <a href="<spring:message code="idp.logo.target.url" />" target="_blank">
       <img src="<%= request.getContextPath() %><spring:message code="idp.logo" />"
        alt="<spring:message code="idp.logo.alt-text" text="logo" />">
    </a>
   </header>
 
   <div id="tou-content">
    <spring:message code="my-tou.text" text="Terms of Use" />
   </div>
 
   <footer>
    <div class="container container-footer">
     <p class="footer-text">
      <strong>
       &copy; <spring:message code="idp.logo.alt-text" /> <spring:message code="idp.url.copyyear" /> |
       <a title="Impressum" href="<spring:message code="idp.url.imprint" />" target="_blank">
        Impressum
       </a>
      </strong>
     </p>
    </div>
   </footer>
  </div>
 
 </body>
</html>

Erzeugen Sie die IdP-War Datei neu:

root@idp:~# JAVA_HOME=/usr /opt/shibboleth-idp/bin/build.sh

Testen Sie nochmal einen Login mithilfe der DFN-Test-SP(s) und überzeugen Sie sich, dass die Nutzungsbedingungen angezeigt werden.

Nach der Zustimmung zu den Nutzungsbedingungen werden die Benutzer*innen noch nach ihrer Zustimmung zur Attributfreigabe an den SP gefragt. Ihre Entscheidungen werden clientseitig als Cookies gespeichert, was für den initialen Test-Betrieb ausreichend ist.

Weiterführende Informationen finden Sie im Shibboleth Wiki.

Per Default ist auf der Seite, auf der die zu übertragenden Attribute angezeigt werden, der Radiobutton aktiv, der die nochmalige Anzeige der Attribute beim nächsten Zugriff auf den jeweiligen SP deaktiviert. Sollte dies aus datenschutzrechtlichen Gründen nicht gewollt sein, kann durch einen Eingriff in die Datei ./views/intercept/attribute-release.vm erreicht werden, dass die Option voreingestellt ist, die zu übertragenden Attribute auch beim nächsten Mal angezeigt zu bekommen.
Hierzu muss jeweils die Zeile

<input id="_shib_idp_doNotRememberConsent" type="radio" name="_shib_idp_consentOptions" value="_shib_idp_doNotRememberConsent">

in

<input id="_shib_idp_doNotRememberConsent" type="radio" name="_shib_idp_consentOptions" value="_shib_idp_doNotRememberConsent" checked> 

und

<input id="_shib_idp_rememberConsent" type="radio" name="_shib_idp_consentOptions" value="_shib_idp_rememberConsent" checked>

in

<input id="_shib_idp_rememberConsent" type="radio" name="_shib_idp_consentOptions" value="_shib_idp_rememberConsent">

geändert werden.

Attribute, die reine Verwaltungsinformationen ohne Personenbezug wie z.B. Level of Assurance transportieren, können ggf. vom User Consent ausgenommen werden:

./conf/intercept/consent-intercept-config.xml

 ...
    <util:set id="shibboleth.consent.attribute-release.IgnoredAttributeIDs">
        <value>eduPersonAssurance</value>
    </util:set>
 ...