~~NOTOC~~
======Upgrade von IdP 3.x======
{{INLINETOC 2}}


===== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie =====

https://wiki.shibboleth.net/confluence/display/IDP30/Upgrading. Etwas ausführlicher ist die Anleitung von [[https://www.switch.ch/aai/guides/idp/installation/#keepinguptodate|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 [[https://www.switch.ch/aai/guides/idp/installation/#upgrading|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 [[de:shibidp:config-i18n|Sprachdatei]] unter dem Pfad ''<installationspfad>/system/messages/messages_de.properties'' (meist: ''/opt/shibboleth-idp/system/messages/messages_de.properties'') liegt.

===== Überblick über die Konfigurationsänderungen ab IdP v3.4.0 - Vorbereitung auf IdP v4.x =====
<callout color="#ff9900" title="Wichtiger Hinweis">
Als Voraussetzung für ein erfolgreiches Upgrade auf Version 4.x sollte zuvor mindestens die Version Shib IdP 3.4.6, installiert worden sein. Siehe hierzu im Shibboleth Wiki unter https://wiki.shibboleth.net/confluence/display/IDP4/Upgrading
</callout>
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 [[https://wiki.shibboleth.net/confluence/display/IDP30/ReleaseNotes#ReleaseNotes-3.4.0(October10,2018) | Release Notes]] sind wie immer im Shibboleth-Wiki. Dort finden Sie ebenfalls eine vollständige [[https://wiki.shibboleth.net/confluence/display/IDP30/DeprecatedIdPV4|Übersicht über abgekündigte Konfigurationsdirektiven (DeprecatedIdPV4)]].

==== conf/idp.properties ====
  - Sicherstellen, dass ''idp.cookie.secure = true'' gesetzt ist (es sei denn, es soll explizit nicht so sein):<code>
idp.cookie.secure = true
[...]
</code>
  - Ä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''<file xml 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}
[...]
</file>

==== conf/c14n/subject-c14n.xml ====
Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert):
<file xml 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" /> -->
[...]
</file>

==== conf/attribute-resolver.xml ====
  - 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.<file xml 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>
    [...]
</file>
    * **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.<file xml 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>
    [...]
</file>
    * **Abhängigkeiten in Data Connectors** müssen nach demselben Prinzip angepasst werden:<file xml 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></file>

==== metadata/idp-metadata.xml mit Ablaufdatum ====
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.<file xml 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">

[...]
</file>

==== conf/ldap.properties ====
Folgende Zeile muss in den LDAP-Einstellungen ab Shibboleth 3.4.4 aktualisiert werden, falls vorhanden:
<file xml 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)
</file>

===== Betriebssystem-Upgrade auf Debian 10 =====

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 [[de:shibidp:prepare-tomcat|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:<code>
[Unit]
After=mariadb.service
Wants=mariadb.service
[Service]
ReadWritePaths=/opt/shibboleth-idp/logs/
ReadWritePaths=/opt/shibboleth-idp/metadata/</code>
  * Shibboleth-IdP neu bauen (bin/build.sh)
  * falls nötig: [[https://doku.tid.dfn.de/de:shibidp3config-idm#java-version|LDAP-Workaround aktivieren]]
  * Anpassen der Berechtigungen von User/Gruppe ''tomcat8'' zu ''tomcat''
  * Deinstallation alter Pakete

{{tag>archiv}}