Upgrade von IdP 3.x

https://wiki.shibboleth.net/confluence/display/IDP30/Upgrading. Etwas ausführlicher ist die Anleitung von SWITCH.

Unter Linux ist insbesondere darauf zu achten, dass beim Upgrade die Schreib-/Leseberechtigungen korrekt gesetzt werden (Parameter -Didp.conf.filemode=644 beim Aufruf von ./bin/install.sh). Siehe hierzu auch die Anleitung von SWITCH unter 8.2. Common upgrade instructions for the Shibboleth IdP 3.

Für den Fall, dass die deutsche Übersetzung danach fehlt, stellen Sie sicher, dass die Sprachdatei unter dem Pfad <installationspfad>/system/messages/messages_de.properties (meist: /opt/shibboleth-idp/system/messages/messages_de.properties) liegt.

Ab IdP v3.4.0 werden Konfigurationsparameter als veraltet geloggt, die in Version 4.x nicht mehr vorkommen werden. An dieser Stelle sammeln wir fortlaufend die wichtigsten Änderungen. Das erklärte Ziel der Shibboleth-Entwickler*innen ist es, dass eine mitgepflegte Konfiguration nach einem Upgrade auf IdP v4.x fehlerfrei startet. Die jeweiligen vollständigen Release Notes sind wie immer im Shibboleth-Wiki. Dort finden Sie ebenfalls eine vollständige Übersicht über abgekündigte Konfigurationsdirektiven (DeprecatedIdPV4).

1. Sicherstellen, dass idp.cookie.secure = true gesetzt ist (es sei denn, es soll explizit nicht so sein):

   idp.cookie.secure = true
   [...]

2. Änderung der folgenden zwei Direktiven:
   • idp.consent.userStorageKey ersetzen durch idp.consent.attribute-release.userStorageKey und idp.consent.terms-of-use.userStorageKey
   • idp.consent.userStorageKeyAttribute ersetzen durch idp.consent.attribute-release.userStorageKeyAttribute und idp.consent.terms-of-use.userStorageKeyAttribute

     conf/idp.properties

     # Beispiel:
     [...]
     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}
     [...]

Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert):

conf/c14n/subject-c14n.xml

[...]
<!--
This is installed to support the old mechanism of using PrincipalConnectors in the attribute resolver to map SAML Subjects back into principals. If you don't use those (or this is a new install) you can remove this.
-->
<!-- <ref bean="c14n/LegacyPrincipalConnector" /> -->
[...]

1. Im Attribute Resolver wird die Dependency-Direktive ersetzt.
   • Wenn die Dependency sich auf einen unten definierten Data Connector bezieht, wird ab IdP v3.4.2 stattdessen InputDataConnector verwendet. Bei jedem InputDataConnector muss das zu holende Attribut mit attributeNames mit angegeben werden. Damit wird die sourceAttributeID ersetzt.

     conf/attribute-resolver.xml

     # bis IdP v3.3.x:
         [...]
         <AttributeDefinition id="mail" xsi:type="Simple" sourceAttributeID="mail">
             <Dependency ref="myLDAP" />
                 <DisplayName xml:lang="en">E-mail</DisplayName>
                 <DisplayName xml:lang="de">E-Mail</DisplayName>
                 <DisplayDescription xml:lang="en">E-Mail address</DisplayDescription>
                 <DisplayDescription xml:lang="de">E-Mail Adresse</DisplayDescription>
             <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
         </AttributeDefinition>
         [...]
      
     # ab IdP v3.4.x:
         [...]
         <AttributeDefinition id="mail" xsi:type="Simple">
             <InputDataConnector ref="myLDAP" attributeNames="mail"/>
             <DisplayName xml:lang="en">E-mail</DisplayName>
             <DisplayName xml:lang="de">E-Mail</DisplayName>
             <DisplayDescription xml:lang="en">E-Mail address</DisplayDescription>
             <DisplayDescription xml:lang="de">E-Mail Adresse</DisplayDescription>
             <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false"/>
         </AttributeDefinition>
         [...]

   • Wenn die Dependency sich auf ein anderes, in dieser Datei definiertes Attribut bezieht, das in conf/attribute-resolver.xml definiert wird, wird stattdessen InputAttributeDefinition verwendet.

     conf/attribute-resolver.xml

         [...]
         <AttributeDefinition id="uid" xsi:type="PrincipalName">
             <DisplayName xml:lang="en">User Name</DisplayName>
             <DisplayName xml:lang="de">Nutzerkennung</DisplayName>
             <DisplayDescription xml:lang="en">Local User Id</DisplayDescription>
             <DisplayDescription xml:lang="de">Nutzerkennung der Heimateinrichtung</DisplayDescription>
             <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" encodeType="false"/>
         </AttributeDefinition>
      
         <AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" scope="%{idp.scope}">
             <InputAttributeDefinition ref="uid" />
             <DisplayName xml:lang="en">Principal name</DisplayName>
             <DisplayName xml:lang="de">Netz-Id</DisplayName>
             <DisplayDescription xml:lang="en">A unique identifier for a person, mainly for inter-institutional user identification</DisplayDescription>
             <DisplayDescription xml:lang="de">Eindeutige, einrichtungsübergreifende Nutzerkennung</DisplayDescription>
             <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" encodeType="false" />
         </AttributeDefinition>
         [...]

   • Abhängigkeiten in Data Connectors müssen nach demselben Prinzip angepasst werden:

     conf/attribute-resolver.xml

         <DataConnector id="StoredId" xsi:type="StoredId"
             generatedAttributeID="persistentID"
             salt="%{idp.persistentId.salt}"
             queryTimeout="0">
             <InputDataConnector ref="myLDAP" attributeNames="%{idp.persistentId.sourceAttribute}"/>
             <BeanManagedConnection>shibboleth.MySQLDataSource</BeanManagedConnection>
         </DataConnector>

Ab Shib IdP v3.4.x steht nach einer Neuinstallation ein Ablaufdatum in den IdP-Metadaten (metadata/idp-metadata.xml), das entfernt werden muss. Im folgenden Beispiel muss validUntil=„2019-05-22T11:01:10.621Z“ gelöscht werden.

metadata/idp-metadata.xml

<?xml version="1.0" encoding="UTF-8"?>
<!--
     This is example metadata only. Do *NOT* supply it as is without review,
     and do *NOT* provide it in real time to your partners.
 
     This metadata is not dynamic - it will not change as your configuration changes.
-->
<EntityDescriptor  xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" xmlns:req-attr="urn:oasis:names:tc:SAML:protocol:ext:req-attr" validUntil="2019-05-22T11:01:10.621Z" entityID="https://localhost.localdomain/idp/shibboleth">
 
[...]

Folgende Zeile muss in den LDAP-Einstellungen ab Shibboleth 3.4.4 aktualisiert werden, falls vorhanden:

conf/ldap.properties

# alt - mit dem Attribut CN als Suchfilter:
# idp.attribute.resolver.LDAP.searchFilter = (CN=$requestContext.principalName)
# neu - mit dem Attribut CN als Suchfilter:
idp.attribute.resolver.LDAP.searchFilter = (CN=$resolutionContext.principal)

Debian 10 kommt mit Tomcat9 und Java 11. Das Upgrade besteht grob aus folgenden Schritten. Danke an den Kollegen aus Bremerhaven!

• System-Upgrade
• Installation der neuen Pakete (tomcat9, mariadb-server, libmariadb-java, libtaglibs-standard-impl-java, default-libmysqlclient-dev bzw. libmariadb-dev)
• Anpassen der Default-Java-Version (update-alternatives –config java)
• Prüfen der Tomcat-Konfiguration
• Kopieren der Catalina/localhost-Config zu Tomcat9
• „/usr/share/java/“ zu /etc/tomcat9/catalina.properties hinzufügen (common.loader)
• Anpassen der /etc/default/tomcat9
• systemctl edit tomcat9:

  [Unit]
  After=mariadb.service
  Wants=mariadb.service
  [Service]
  ReadWritePaths=/opt/shibboleth-idp/logs/
  ReadWritePaths=/opt/shibboleth-idp/metadata/

• Shibboleth-IdP neu bauen (bin/build.sh)
• falls nötig: LDAP-Workaround aktivieren
• Anpassen der Berechtigungen von User/Gruppe tomcat8 zu tomcat
• Deinstallation alter Pakete