Dies ist eine alte Version des Dokuments!


Server-Side Storage

Standardmäßig werden Informationen zu Sessions, User Consent (bzgl. Attributfreigabe) und Persistent IDs clientseitig in Cookies abgelegt. Wir betrachten die clientseitige Speicherung nur als initiale „Notlösung“, damit der IdP auch ohne 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. persistentIds oder Single-Logout). Nur so kann sichergestellt werden, dass bei Attribute Queries, die Entscheidungen des/der Nutzers/Nutzerin hinsichtlich Attributfreigabe berücksichtigt werden.

persistentId?

PersistentIds werden vom IdP pro Useraccount und pro Service Provider automatisch generiert. Sie sind pseudonym und können am SP zur Wiedererkennung und Personalisierung verwendet werden. Nur am IdP ist ist ersichtlich, welchen Nutzer*innen die persistentIds zuzuordnen sind. persistentIds sind keine normalen Attribute, sondern sogenannte SAML2 NameIDs. Ihre Freigabe wird in der Konfigurationsdatei ./conf/relying-party.xml reguliert.

Attribute Query?

Bei einer Attribute Query fragt ein Service Provider direkt beim IdP Nutzerdaten ab, also ohne, dass Nutzer*innen einen Loginvorgang angestoßen haben. Dies tun manche SPs, um Informationen darüber zu bekommen, ob Useraccounts am IdP noch aktiv sind. Für Attribute Queries wird gerne die persistentId verwendet.

Wir zeigen die Vorgehensweise hier anhand von MariaDB. Es ist aber möglich, andere Datenbank-Software zu verwenden, etwa MySQL, Oracle oder Postgres, siehe hierzu die Dokumentation im Shibboleth-Wiki. Ein Beispiel für PostgreSQL findet sich bei SWITCHAAI.

root@idp:~# apt install mariadb-server mariadb-client libmariadb-java
root@idp:~# ln -s /usr/share/java/mariadb-java-client.jar /var/lib/tomcat9/lib/mariadb-java-client.jar

Starten Sie Tomcat neu um die neuen Einstellungen zu aktivieren:

root@idp:~# systemctl restart tomcat9

Die Datenbank und der Datenbank-Benutzeraccount müssen manuell erstellt werden. Dann werden noch zwei Tabellen angelegt:

  • StorageRecords für Sessions und User Consent-Informationen
  • shibpid für die persistentIds
mysql> SET NAMES 'utf8';
SET CHARACTER SET utf8;
CHARSET utf8;
CREATE DATABASE IF NOT EXISTS shibboleth CHARACTER SET=utf8;
USE shibboleth;
 
mysql> CREATE TABLE IF NOT EXISTS StorageRecords (
  context varchar(255) NOT NULL,
  id varchar(255) NOT NULL,
  expires bigint(20) DEFAULT NULL,
  value longtext NOT NULL,
  version bigint(20) NOT NULL,
  PRIMARY KEY (context, id)
);
 
mysql> CREATE TABLE IF NOT EXISTS shibpid (
    localEntity VARCHAR(255) NOT NULL,
    peerEntity VARCHAR(255) NOT NULL,
    persistentId VARCHAR(50) NOT NULL,
    principalName VARCHAR(50) NOT NULL,
    localId VARCHAR(50) NOT NULL,
    peerProvidedId VARCHAR(50) NULL,
    creationDate TIMESTAMP NOT NULL,
    deactivationDate TIMESTAMP NULL,
    PRIMARY KEY (localEntity, peerEntity, persistentId)
);
 
mysql> CREATE USER 'shibboleth'@'localhost' IDENTIFIED BY 'GeHEIM007';
 
mysql> GRANT ALL PRIVILEGES ON shibboleth.* TO 'shibboleth'@'localhost';
 
mysql> FLUSH PRIVILEGES;

Der DB-Zugriff wird über den JPAStorageService gekapselt. Dieser wird in ./conf/global.xml definiert. Diese Datei ist im Auslieferungszustand leer (bis auf Kommentare). Füllen Sie sie wie folgt:

./conf/global.xml
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:context="http://www.springframework.org/schema/context"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:p="http://www.springframework.org/schema/p"
       xmlns:c="http://www.springframework.org/schema/c"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
                           http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context.xsd
                           http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd"
 
       default-init-method="initialize"
       default-destroy-method="destroy">
 
    <!-- Use this file to define any custom beans needed globally. -->
 
    <!-- Die folgenden Werte sind Default-Werte:
         p:maxActive="100"
         p:maxIdle="100"
         Es ist unter Umständen nötig, dass Sie diese Werte je nach Auslastung Ihres IdP anpassen,
         ebenso wie die Konfiguration Ihres MySQL-Servers. -->
 
        <bean id="shibboleth.MySQLDataSource"
              class="%{mysql.class}"
              p:driverClassName="org.mariadb.jdbc.Driver"
              p:url="%{mysql.url}"
              p:username="%{mysql.username}"
              p:password="%{mysql.password}"
              p:maxWait="15000"
              p:testOnBorrow="true"
              p:maxActive="100"
              p:maxIdle="100"
              p:validationQuery="select 1"
              p:validationQueryTimeout="5" />
 
        <bean id="shibboleth.JPAStorageService"
              class="org.opensaml.storage.impl.JPAStorageService"
              p:cleanupInterval="%{idp.storage.cleanupInterval:PT10M}"
              c:factory-ref="shibboleth.JPAStorageService.EntityManagerFactory" />
 
        <bean id="shibboleth.JPAStorageService.EntityManagerFactory"
              class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
            <property name="packagesToScan" value="org.opensaml.storage.impl"/>
            <property name="dataSource" ref="shibboleth.MySQLDataSource"/>
            <property name="jpaVendorAdapter" ref="shibboleth.JPAStorageService.JPAVendorAdapter"/>
            <property name="jpaDialect">
                <bean class="org.springframework.orm.jpa.vendor.HibernateJpaDialect" />
            </property>
        </bean>
 
        <bean id="shibboleth.JPAStorageService.JPAVendorAdapter"
              class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter"
              p:generateDdl="true"
              p:database="MYSQL"
              p:databasePlatform="org.hibernate.dialect.MySQL5Dialect" />
 
</beans>

Die Properties für den Datenbank-Zugriff werden jetzt noch in ./conf/idp.properties ergänzt:

/opt/shibboleth-idp/conf/idp.properties
# ...
mysql.class    = org.apache.tomcat.jdbc.pool.DataSource
mysql.url      = jdbc:mysql://localhost:3306/shibboleth
mysql.username = shibboleth
# ...

Das Passwort gehört wieder in die Datei ./credentials/secrets.properties:

mysql.password = GeHEIM007

Starten Sie Tomcat neu, um sicherzustellen, dass die global.xml ohne Probleme eingelesen werden kann:

root@idp:~# systemctl restart tomcat9

Die persistentId wird in drei Schritten aktiviert:

Erstens wird festgelegt, wie die Id generiert und abgelegt werden soll:

/opt/shibboleth-idp/conf/saml-nameid.properties
# ein Attribut aus attribute-resolver.xml als unique Identifier, dabei wird hier der Wert der "id"
# dieses Attributes aus attribute-resolver.xml referenziert und _nicht_ der Attribut-Name aus dem IdM!
# in den allermeisten Fällen wird das immer 'uid' sein, auch bei Microsoft AD (dort dient das IdM-
# Attribut 'sAMAccountName' bzw. neuerdings 'cn' als Quelle fur das IdP-Attribut 'uid')
idp.persistentId.sourceAttribute = uid
#idp.persistentId.useUnfilteredAttributes = true
# Do *NOT* share the salt with other people, it's like divulging your private key.
#idp.persistentId.algorithm = SHA
idp.persistentId.salt = MöglichstBeliebigUndGeHeim-mindestens-16bytes
 
# To use a database, use shibboleth.StoredPersistentIdGenerator
idp.persistentId.generator = shibboleth.StoredPersistentIdGenerator
# For basic use, set this to a JDBC DataSource bean name:
idp.persistentId.dataSource = shibboleth.MySQLDataSource

Hinweise zur Wahl des Quellatributs:

  • Als Quellattribut aus dem IdM für die persistentId muss man ein IdM-Attribut nehmen, welches auch über die Zeit für alle Benutzer eindeutig ist. Oft ist dies das IdM-Attribut 'uid' (oder bei AD 'sAMAccountName' bzw. neuerdings 'cn'). Sollte dies bei Ihnen nicht der Fall sein, d.h. diese Attribute werden für neue User recycled (auch aus anderen Gründen nicht zu empfehlen!), dann muss ein anderes IdM-Attribut gefunden werden.
  • Eine Möglichkeit, dieses Problem zu umgehen, besteht darin, sich ein neues Attribut in attribute-resolver.xml zu definieren. Dieses Attribut könnte zum Beispiel aus einem Hash aus uid und dem Anlegedatum des Accounts bestehen.
  • Beispiele zur Generierung finden Sie unter Persistent ID - Sonderfälle.

Zweitens wird die Java-Bean für die Generierung aktiviert indem der Eintrag für shibboleth.SAML2PersistentGenerator ent-kommentieren wird:

/opt/shibboleth-idp/conf/saml-nameid.xml
<beans ...>
    <!-- ... -->
    <!-- SAML 2 NameID Generation -->
    <util:list id="shibboleth.SAML2NameIDGenerators">
 
        <ref bean="shibboleth.SAML2TransientGenerator" />
 
        <!-- Uncommenting this bean requires configuration in saml-nameid.properties. -->
 
        <ref bean="shibboleth.SAML2PersistentGenerator" />
 
    </util:list>
    <!-- ... -->
</beans>

Drittens wird die Verarbeitung der Id aktiviert:

/opt/shibboleth-idp/conf/c14n/subject-c14n.xml
<beans ...>
    <!-- ... -->
    <util:list id="shibboleth.SAMLSubjectCanonicalizationFlows">
        <!-- ... -->
 
        <!-- Handle a SAML 2 persistent ID, provided a stored strategy is in use. -->
        <ref bean="c14n/SAML2Persistent" />
 
        <!-- ... -->
    </util:list>
    <!-- ... -->
</beans>

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:

./conf/c14n/simple-subject-c14n-config.xml
   ...
   <util:constant id="shibboleth.c14n.simple.Lowercase" static-field="java.lang.Boolean.TRUE"/>
   ...

Damit werden die Usernamen vom IdP nur noch in Kleinbuchstabenform verarbeitet und in die Datenbank geschrieben.

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-Unterstützung im IdP ermöglicht. Außerdem können nun bei Attribute Queries Nutzer-Entscheidungen zu Attributfreigaben berücksichtigt werden (siehe unten).

/opt/shibboleth-idp/conf/idp.properties
...
# Set to "shibboleth.StorageService" for server-side storage of user sessions
idp.session.StorageService = shibboleth.JPAStorageService
 
# Set to "shibboleth.StorageService" or custom bean for alternate storage of consent
idp.consent.StorageService = shibboleth.JPAStorageService
 
# Set to "shibboleth.consent.AttributeConsentStorageKey" to use an attribute
# to key user consent storage records (and set the attribute name)
idp.consent.attribute-release.userStorageKey = shibboleth.consent.PrincipalConsentStorageKey
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
#idp.consent.allowDoNotRemember = true
# damit der User für jeden SP mindestens einmal einwilligen muß sollte
# die Möglichkeit für eine globale Einwilligung abgeschaltet werden:
idp.consent.allowGlobal = false
#idp.consent.allowPerAttribute = false
 
# Damit auch bei neuem Wert eines Attributes und bei neuem Terms-Of-Use-Text der
# User erneut abnicken muss. Da jetzt statt Browser-Cookies eine lokale DB zur
# Verfügung steht sollte dieses sinnvolle Feature aktiviert werden!
idp.consent.compareValues = true

Damit bei Attribute Queries Nutzer-Entscheidungen zur Attributfreigabe berücksichtigt werden, muss in ./conf/intercept/consent-intercept-config.xml die entsprechende Condition gesetzt werden:

./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" />

Starten Sie Tomcat neu, um die neuen Einstellungen zu aktivieren:

root@idp:~# systemctl restart tomcat9

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 Doku im Shibboleth-Wiki), kann die SAML2.SSO-Bean-Definition bei Bedarf entsprechend erweitert werden:

/conf/relying-party.xml
<beans ...>
  <!-- ... -->
  <bean id="shibboleth.DefaultRelyingParty" parent="RelyingParty">
    <property name="profileConfigurations">
       <list>
         <!-- ... -->
         <bean parent="SAML2.SSO"
               p:postAuthenticationFlows="#{{'terms-of-use', 'attribute-release'}}"
               p:nameIDFormatPrecedence="#{{'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent', 'urn:oasis:names:tc:SAML:2.0:nameid-format:transient'}}"/>
         <!-- ... -->
        </list>
    </property>
  </bean>
  <!-- ... -->
</beans>

Starten Sie Tomcat neu, um die neuen Einstellungen zu aktivieren (dabei Logdateien mitverfolgen!):

root@idp:/opt/shibboleth-idp# service tomcat8 restart

Testen Sie nochmals einen Login mithilfe der DFN-Test-SP(s) und überzeugen Sie sich, dass die 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.

Falls die persistentId nur an ausgewählte SPs übertragen werden soll, so finden sich hier einige Beispiele.

Weiter geht es mit Single Logout.

  • Zuletzt geändert: vor 4 Jahren