Upgrade von IdP 3.x auf 4.x

Laut der Shibboleth-Dokumentation muss der IdP 4.0 direkt auf einen funktionsfähigen IdP Version 3.4.6 oder 3.4.7 installiert werden! Man erhält kein fehlerfrei funktionierendes System, wenn man die Version 4.x separat installiert und die Konfiguration der Version in die Installation hineinkopiert.

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. Die IdP-Version 3.4.7 ist erst nach der 4.0.0 erschienen. Auch von dieser Version können Sie selbstverständlich upgraden.

Daher bringen Sie Ihren IdP bitte zunächst auf die Version 3.4.6 oder 3.4.7: 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.6 laufen müssen. Beobachten Sie das idp-process.log und bereinigen Sie alle Deprecation Warnings.

Die groben Schritte:

• Datensicherung von idp.home und Datenbank
• Release Notes studieren
• den Installer (.bin/install.sh) aufrufen und den IdP - wie bei den vorherigen Updates ins gewohnte Verzeichnis installieren
• die Datei ./war/idp.war neu bauen mit ./bin/build.sh

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.

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

• 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>

• 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:

  conf/attribute-resolver.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>