Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
de:shibidp3upgrade [2018/11/19 15:45] – [Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie] Wolfgang Pempede:shibidp3upgrade [2022/05/02 15:39] (aktuell) – Archiv-Tag Silke Meyer
Zeile 1: Zeile 1:
-======Upgrade======+~~NOTOC~~ 
 +======Upgrade von IdP 3.x====== 
 +{{INLINETOC 2}}
  
-==== Migration 2.x --> 3.x ==== 
  
-Ein [[https://wiki.shibboleth.net/confluence/display/IDP30/UpgradingFromV2|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.+===== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie =====
  
-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:+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]]. \\ 
  
-  * lassen Sie den produktiven IdP 2.x zunächst unverändert weiter laufen +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]].
-  * 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.+
  
 +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.
  
-==== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie ====+===== Ü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)]].
  
-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 [[https://www.switch.ch/aai/guides/idp/installation/#keepinguptodate|SWITCH]]. \\ +==== 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>
  
-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.s''h). Siehe hierzu die Anleitung von SWITCH unter [[https://www.switch.ch/aai/guides/idp/installation/#upgrading|8.2. Common upgrade instructions for the Shibboleth IdP 3]].+==== 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>
  
-Für den Fall, dass die deutsche Übersetzung danach fehlt, stellen Sie sicher, dass die [[https://wiki.shibboleth.net/confluence/display/IDP30/MessagesTranslation#MessagesTranslation-v3.3IdentityProvider3.3|Sprachdatei]] unter dem Pfad ''<installationspfad>/system/messages/messages_de.properties'' (meist: ''/opt/shibboleth-idp/system/messages/messages_de.properties'') liegt.+==== 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}}
  • Zuletzt geändert: vor 5 Jahren