Dies ist eine alte Version des Dokuments!


Upgrade

Ein Upgrade von IdP Version 2.x auf 3.x auf ein und demselben Host wird von den Entwicklern nicht empfohlen, da sich die Konfigurationen zu sehr unterscheiden und es keine automatische Konvertierung gibt.

Um Ihren IdP 2.x in der DFN-AAI auf 3.x zu migrieren, empfehlen wir daher folgende Vorgehensweise in der beide IdP-Versionen während der Migration parallel betrieben werden:

  • lassen Sie den produktiven IdP 2.x zunächst unverändert weiter laufen
  • installieren Sie den IdP 3.x auf einem (neuen) Testsystem von Grund auf wie in diesem Wiki beschrieben
  • Testen Sie damit ausführlich in der DFN-AAI-Test, bis Sie gut mit der Konfiguration vertraut sind:
    • konfigurieren Sie attribut-resolver und attribut-filter analog zu Ihrem IdP 2.x und überzeugen Sie sich mithilfe unserer Test-SPs dass die Attribute so übermittelt werden, wie es Ihr IdP 2.x tut.
    • migrieren Sie die bestehende persistentId-Datenbank vom IdP 2.x auf die Testinstallation und verifizieren Sie, dass die IDs unverändert geblieben sind.
  • installieren Sie den IdP 3.x so auf einem neuen Produktivsystem, dass die Metadaten identisch zu Ihrem IdP 2.x sind, indem Sie bei der Installation den gleichen DNS-Namen wählen wie ihr bestehendes 2.x-System!
    • die entityID des IdP 3.x entspricht damit der des IdP 2.x
    • die Kommunikations-URLs in den Metadaten bleiben unverändert
    • ersetzen Sie auf dem IdP 3.x private-Key- und Zertifikatsdatei durch die entsprechenden Dateien vom IdP 2.x
  • die Metadaten des IdP 3.x sind damit identisch zum IdP 2.x; es muss in der DFN-AAI-Metadatenregistrierung nichts eingetragen oder geändert werden. Insbesondere ist dort nach wie vor nur ein produktiver IdP eingetragen!
  • Übernehmen Sie die Attribute-, NameID-, Datenbank- und sonstige Konfigurationen von Ihrer 3.x Testinstallation auf das neue Produktiv-System.
  • ersetzen Sie in Ihrem DNS-Server die IP des alten IdP 2.x durch die IP des neuen IdP 3.x.
  • lassen Sie den IdP 2.x noch so lange laufen, bis sich die DNS-Änderung weltweit verbreitet hat.
  • wenn Sie sehen, dass am IdP 2.x keine Zugriffe mehr erfolgen, können Sie ihn abschalten.

https://wiki.shibboleth.net/confluence/display/IDP30/Upgrading (erfolgreich getestet mit Upgrade von 3.1.1 auf 3.1.2). 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.

Englischsprachige Quelle im offiziellen Shibboleth-Wiki: https://wiki.shibboleth.net/confluence/display/IDP30/DeprecatedIdPV4

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 Änderungen. Für die vollständigen Release Notes sei auf das Shibboleth-Wiki verwiesen.

conf/idp.properties

  1. Sicherstellen, dass idp.cookie.secure = true gesetzt ist (es sei denn, es soll explizit nicht so sein).
  2. Änderung der folgenden zwei Direktiven:
    • idp.consent.userStorageKey ersetzen durch idp.consent.attribute-release.userStorageKey
    • idp.consent.userStorageKeyAttribute ersetzen durch idp.consent.attribute-release.userStorageKeyAttribute

Beispiel:

idp.cookie.secure = true
[...]
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}

conf/c14n/subject-c14n.xml

Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert):

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

conf/attribute-resolver.xml (3.4.2)

Statt Dependency und sourceAttributeID werden InputDataConnector und InputAttributeDefinition verwendet.

Vorher:

    <AttributeDefinition xsi:type="Simple" id="mail" 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="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" />
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
    </AttributeDefinition>

Nachher:

    <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="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false"/>
        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false"/>
    </AttributeDefinition>
  • Zuletzt geändert: vor 5 Jahren