Dies ist eine alte Version des Dokuments!


Upgrade auf Shibboleth IdP 4.x

Laut der Shibboleth-Dokumentation soll der IdP 4.0.x direkt auf einen funktionsfähigen IdP Version 3.4.6, 3.4.7 oder 3.4.8 installiert werden! Man erhält kein fehlerfrei funktionierendes System, wenn man die Version 4.x separat installiert und die Konfiguration eines 3er-IdP einfach in die neue Installation hineinkopiert (z.B. doppelte Attribute). Es ist natürlich möglich, die geprüften Inhalte in eine Neuinstallation zu übertragen.

Anmerkung zu 4.1.x: Nach dem Aufbau dieser Dokumentationsseite ist die IdP-Version 4.1.x erschienen. Es ist möglich, auf gewohnte Weise auf diese Version zu aktualisieren. Ab 4.1.x enthält der IdP jedoch einige grundsätzliche Änderungen und viele Vereinfachungen. Das Aufräumen einer aktualisierten Installation ist sehr kleinteilig, fehleranfällig und aufwändig. Wir empfehlen daher bei einem Upgrade auf 4.1.x einen neuen IdP aufzusetzen.

Hier können Sie unseren Vortrag „Upgrade auf Shibboleth IdP 4.0.x“ vom 17.11.2020 anschauen oder sich die Folien herunterladen. Zu dem Zeitpunkt war der IdP 4.1.x noch nicht erschienen. Die Themen:

  • Intro (bis Minute 3:00)
  • Allgemeine Neuerungen im IdP 4.0.x (3:00 - 7:16)
  • Neuerungen, die nur auf neu installierten 4er IdPs aktiv sind (7:16 - 13:42)
    • Die Attribute Registry (13:42 - 21:53)
    • Attribut-Export aus Data Connectors (21:53 - 23:17)
  • Vorstellung der neuen Attribute SAML Subject ID und SAML Pairwise ID (23:17 - 31:17)
  • Vorgehensweise beim Upgrade (31:17 - 36:35) (siehe auch unten auf dieser Seite)
  • Wann empfehlen wir eine Neuinstallation? (36:35 - 39:10)
  • Ausblick auf Shibboleth 4.1 (ab 39:10)

Die Aufzeichnung enthält Kapitelmarken, mit denen Sie in einem geeigneten Player springen können.

Vorgehen in Abhängigkeit Ihrer IdP-Version

Wir empfehlen, je nach dem, welche 3er-Version Sie betreiben, unterschiedliche Wege zu gehen, die unten dokumentiert sind:
  • Anmerkung zu 4.1.x: Nach dem Aufbau dieser Dokumentationsseite ist die IdP-Version 4.1.x erschienen. Es ist möglich, auf diese Version zu aktualisieren (getestet mit einem Upgrade von 3.4.8 über 4.0.1 auf 4.1.0). Ab 4.1.x enthält der IdP jedoch einige grundsätzliche Änderungen und viele Vereinfachungen. Das Aufräumen einer aktualisierten Installation ist sehr kleinteilig und aufwändig. Es lohnt sich ggf., die Version 4.1.x neu aufzusetzen. Die Upgrade-Deadline am 30.06.2021 bleibt dadurch unberührt.

Die IdP-Versionen 3.4.6, 3.4.7 und 3.4.8 sind upgradefähig.

Die groben Schritte:

  • Datensicherung von idp.home und Datenbank
  • Systemanforderungen prüfen: Java 11 und Tomcat 9+ (bzw. Jetty 9.4+)
  • Release Notes studieren
  • neue Version herunterladen und entpacken
  • den Installer (./bin/install.sh) aufrufen und den IdP - wie bei den vorherigen Updates ins gewohnte Verzeichnis installieren. Unter Linux ist außerdem zu beachten, dass beim Upgrade die Schreib-/Leseberechtigungen korrekt gesetzt werden (Parameter -Didp.conf.filemode=644 beim Aufruf von ./bin/install.sh).
  • die Datei ./war/idp.war neu bauen mit ./bin/build.sh
  • In den Release Notes steht u.a. ein Hinweis auf Änderungen an der LDAP-Konfiguration, die auf der Seite LDAPAuthnConfiguration erläutert sind. Dort wird für die meisten Installationen dazu geraten, zwei Dateien auf den Auslieferungszustand der 4.x zu setzen. Die mitgelieferten Originale finden Sie im dist-Ordner:
    root@idp:~ # cp /opt/shibboleth-idp/dist/conf/authn/ldap-authn-config.xml /opt/shibboleth-idp/conf/authn/ldap-authn-config.xml
    root@idp:~ # cp /opt/shibboleth-idp/dist/conf/authn/password-authn-config.xml /opt/shibboleth-idp/conf/authn/password-authn-config.xml

Was geschieht mit den Änderungen am eigenen IdP?

  • Dateien im Ordner idp.home/system werden (schon immer) bei Upgrades überschrieben. Dies war nie der Ort für eigene Anpassungen - sollten Sie doch Anpassungen vorgenommen haben, übertragen Sie sie bitte an die entsprechenden Stellen in den anderen Ordnern.
  • Dateien in folgenden Ordnern werden bei Upgrades nicht überschrieben: ./conf, ./views, ./messages und ./edit-webapp. Hier sollten Sie also Ihre Konfigurationen, Views oder Templates untergebracht haben.

Attribute Resolver erst später umbauen

Da die IdP-Version 4.1 voraussichtlich etliche Konfigurationsänderungen mit sich bringen wird ([1], [2]), empfehlen wir, nach einem Upgrade von 3.4.6-3.4.8 auf 4.0.1 die alte conf/attribute-resolver.xml beizubehalten. Den Umbau der Syntax und das Einbeziehen der neuen Attribute Registry sollten Sie dann später vornehmen.

In den letzten 3.4.x-Releases wurden bereits alle Syntax- und Konfigurationsparameter-Änderungen als veraltet bemängelt, die in Version 4.0 nicht mehr möglich sind. Mit einer entsprechend mitgepflegten, laufenden IdP 3.4.6-Installation ist das Upgrade auf 4.0 möglich. Je nach dem, welche genaue IdP-Version Sie betreiben, sollten Sie abwägen, welchen Weg Sie gehen möchten. Ab Version 3.4.2 war die Datei conf/attribute-resolver.xml anzupassen. Dies war der aufwändigste Schritt. Wenn Sie ihn schon hinter sich haben, ist es sicher weniger Aufwand, dem Upgradepfad zu folgen.

Daher bringen Sie Ihren IdP bitte zunächst auf die Version 3.4.8: Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie Auf der Seite finden Sie auch einen Überblick über die Konfigurationsänderungen, die im IdP v3.4.8 laufen müssen. Beobachten Sie das idp-process.log (oder nur die Warnungen und Fehler im idp-warn.log) und bereinigen Sie alle Deprecation Warnings.

Ab hier gehen Sie vor, wie im Abschnitt Upgrade von 3.4.6 - 3.4.8 beschrieben.

Wir empfehlen IdP-Betreiber*innen, die noch Shibboleth 3.3.x oder älter haben, eine Neuinstallation des IdP 4.0.1 nach unserem Tutorial durchzuführen. Der Aufwand, alle Änderungen der 3.4.er-Versionen nachzupflegen, ist nicht ganz gering und fehleranfällig. Auf einem neuen System haben Sie die aktuellen Konfigurationsdateien mit den jetzt gesetzten Standardeinstellungen und Konfigurationsparametern. Zudem können Sie das Upgrade wahrscheinlich nicht ohne Aktualisierung des Betriebssystems durchführen (Systemanforderungen). Das neue Produktivsystem sollte am Ende dieselbe EntityId wie das alte Produktivsystem haben. Hier finden Sie eine Schritt-für-Schritt-Anleitung für die Migration des IdP im laufenden Betrieb.

In einer Neuinstallation von Shibboleth IdP 4.x werden IdP-interne Secrets in der separaten Datei secrets.properties gespeichert. Informationen wie LDAP-Bind- oder Datenbank-Credentials sind durch die Zugangsbeschränkungen dieser neuen Datei besser geschützt. Wir empfehlen, das auch bei aktualisierten IdPs nachzuziehen und die entsprechenden Informationen aus idp.properties, ldap.properties oder global.xml auszulagern.

  1. Verlinken Sie die neue Datei als zusätzliche Konfigurationsdatei ganz oben in idp.properties, hier an letzter Stelle:
    conf/idp.properties
    idp.additionalProperties=/conf/ldap.properties, /conf/saml-nameid.properties, /conf/services.properties, /conf/authn/duo.properties, /credentials/secrets.properties
  2. Erstellen Sie die neue Datei /opt/shibboleth-idp/credentials/secrets.properties mit folgenden Parametern (und ggf. weiteren aus Ihrer IdP-Konfiguration):
    /opt/shiboleth-idp/credentials/secrets.properties
    # Access to internal AES encryption key
    idp.sealer.storePassword = <YOUR-SECRET-HERE>
    idp.sealer.keyPassword = <YOUR-SECRET-HERE>
     
    # Default access to LDAP authn and attribute stores. 
    idp.authn.LDAP.bindDNCredential              = <YOUR-LDAP-BIND-CREDENTIAL-HERE>
    idp.attribute.resolver.LDAP.bindDNCredential = %{idp.authn.LDAP.bindDNCredential:undefined}
     
    # Salt used to generate persistent/pairwise IDs, must be kept secret
    idp.persistentId.salt = <YOUR-VERY-LONG-HASH-HERE>
     
    # Access to MySQL database
    mysql.password = <YOUR-MYQSL-PASSWORD-HERE>
  3. Schützen Sie die Datei:
    root@idp:~# chown root:tomcat /opt/shibboleth-idp/credentials/secrets.properties
    root@idp:~# chmod 640 /opt/shibboleth-idp/credentials/secrets.properties

Ein von 3.4.x aktualisierter Shibboleth-IdP verhält sich in Bezug auf den gewählten Verschlüsselungsalgorithmus so wie vor dem Upgrade. Der Algorithmus, der bisher zum Einsatz kam, gilt jedoch nicht mehr als sicher. Bitte schauen Sie sich die unter Konfiguration des Verschlüsselungsalgorithmus gezeigten Möglichkeiten an. Wir zeigen dort einen empfohlenen Weg mit dem neueren Algorithmus AES-GCM und Ausnahmen für SPs, die den Algorithmus noch nicht kennen.

Direkt nach der Aktualisierung auf einen 4.xer IdP erscheinen im Log neue Deprecation Warnings. Wir empfehlen, sie über die Minor Updates hin gleich zu bearbeiten. Hier finden Sie fortlaufend die Einstellungen, die ab 4.x abgekündigt sind.

attribute-resolver.xml

  • Das XML-Attribute failfastInitialize, das zuvor unterhalb des ConnectionPool konfiguriert wurde, wird jetzt direkt beim DataConnector eingestellt.
    conf/attribute-resolver.xml
        <DataConnector id="myLDAP" xsi:type="LDAPDirectory"
            ldapURL="%{idp.attribute.resolver.LDAP.ldapURL}"
            baseDN="%{idp.attribute.resolver.LDAP.baseDN}"
            principal="%{idp.attribute.resolver.LDAP.bindDN}"
            principalCredential="%{idp.attribute.resolver.LDAP.bindDNCredential}"
            useStartTLS="%{idp.attribute.resolver.LDAP.useStartTLS:true}"
            connectTimeout="%{idp.attribute.resolver.LDAP.connectTimeout}"
            trustFile="%{idp.attribute.resolver.LDAP.trustCertificates}"
            responseTimeout="%{idp.attribute.resolver.LDAP.responseTimeout}"
            failFastInitialize="%{idp.pool.LDAP.failFastInitialize:false}">
            <FilterTemplate>
                <![CDATA[
                    %{idp.attribute.resolver.LDAP.searchFilter}
                ]]>
            </FilterTemplate>
            <ConnectionPool
                minPoolSize="%{idp.pool.LDAP.minSize:3}"
                maxPoolSize="%{idp.pool.LDAP.maxSize:10}"
                blockWaitTime="%{idp.pool.LDAP.blockWaitTime:PT3S}"
                validatePeriodically="%{idp.pool.LDAP.validatePeriodically:true}"
                validateTimerPeriod="%{idp.pool.LDAP.validatePeriod:PT5M}"
                expirationTime="%{idp.pool.LDAP.idleTime:PT10M}"/>
        </DataConnector>

attribute-filter.xml

  • Das XML-Element ignoreCase wird ersetzt durch caseSensitive. Um die gleiche Aussage zu erhalten, geben Sie statt ignoreCase='true' jetzt caseSensitive='false' ein. Ein Beispiel aus den Filter Policies (dasselbe kann auch im Attribute Resolver vorkommen):
    conf/attribute-filter.xml
    <AttributeFilterPolicy id="LibraryTermsToAnyone">
      <PolicyRequirementRule xsi:type="ANY" />
      <AttributeRule attributeID="eduPersonEntitlement">
        <PermitValueRule xsi:type="Value" value="urn:mace:dir:entitlement:common-lib-terms"/>
      </AttributeRule>
      <AttributeRule attributeID="eduPersonScopedAffiliation">
        <PermitValueRule xsi:type="OR">
          <Rule xsi:type="Value" value="member"                caseSensitive="false"/>
          <Rule xsi:type="Value" value="library-walk-in"       caseSensitive="false"/>
        </PermitValueRule>
      </AttributeRule>
    </AttributeFilterPolicy>
  • Der xsi:type=„SAML2NameID“ im Attribute Resolver wird für das nächste Major Release abgekündigt. Sie sehen die Warnung, wenn Sie das veraltete Attribut eduPersonTargetedID im Resolver definiert haben. Bitte ignorieren Sie die Warnung vorerst. Sehr viele Service Provider verlangen das Attribut nach wie vor.

Upgrades innerhalb der Produktlinie IdP 4.x

Laut Shibboleth-Wiki werden die Minor- oder Patch-Updates jeweils über die laufende IdP-Version drüber installiert:

  • Sie laden dazu die neueste IdP-Version herunter (unter Linux standardmäßig nach /opt/install) und entpacken sie.
  • Dann führen Sie das interaktive Installationsskript erneut aus. Wichtig ist, dass Sie als Zielverzeichnis das Verzeichnis der laufenden Installation angeben, z.B. /opt/shibboleth-idp unter Linux. Unter Linux ist außerdem zu beachten, dass beim Upgrade die Schreib-/Leseberechtigungen korrekt gesetzt werden (Parameter -Didp.conf.filemode=644 beim Aufruf von ./bin/install.sh).
    root@idp:/opt/install/shibboleth-identity-provider-4.1.4# ./bin/install.sh  -Didp.conf.filemode=644
    Buildfile: /opt/install/shibboleth-identity-provider-4.1.4/bin/build.xml
    
    install:
    Source (Distribution) Directory (press <enter> to accept default): [/opt/install/shibboleth-identity-provider-4.1.4] ? 
    
    Installation Directory: [/opt/shibboleth-idp] ? 
    
    INFO [net.shibboleth.idp.installer.V4Install:155] - Update from version 4.1.3 to version 4.1.4
    INFO [net.shibboleth.idp.installer.BuildWar:72] - Rebuilding /opt/shibboleth-idp/war/idp.war, Version 4.1.4
    INFO [net.shibboleth.idp.installer.BuildWar:81] - Initial populate from /opt/shibboleth-idp/dist/webapp to /opt/shibboleth-idp/webpapp.tmp
    INFO [net.shibboleth.idp.installer.BuildWar:90] - Overlay from /opt/shibboleth-idp/edit-webapp to /opt/shibboleth-idp/webpapp.tmp
    INFO [net.shibboleth.idp.installer.BuildWar:99] - Creating war file /opt/shibboleth-idp/war/idp.war
    
    BUILD SUCCESSFUL
    Total time: 42 seconds

Upgrade-Anleitung mit manueller Tomcat-Installation

Die Kollegen von der Charité Berlin haben eine Anleitung für Ubuntu 18.04 verfasst, in der sie den Tomcat9 manuell installieren: Vielen Dank an Mario Severing für's Teilen!

  • Zuletzt geändert: vor 3 Jahren