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 [2019/07/11 15:30]
Wolfgang Pempe [Migration 2.x --> 3.x]
de:shibidp3upgrade [2019/10/08 10:14] (aktuell)
Wolfgang Pempe [Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie]
Zeile 1: Zeile 1:
 +~~NOTOC~~
 ======Upgrade====== ======Upgrade======
 +{{INLINETOC 2}}
 +===== Migration von IdP 2.x auf 3.4.x =====
  
-==== Migration ​2.x --> ​3.x ====+Ein [[https://​wiki.shibboleth.net/​confluence/​display/​IDP30/​UpgradingFromV2|Upgrade von IdP Version ​2.x auf 3.4.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.
  
-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 empfohlenda sich die Konfigurationen zu sehr unterscheiden und es keine automatische Konvertierung gibt.+Um Ihren IdP 2.x in der DFN-AAI ohne Downtime ​auf 3.4.x zu migrierenempfehlen wir daher folgende Vorgehensweise,​ in der beide IdP-Versionen während der Migration parallel betrieben werden:
  
-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: +==== Schritt 1Testsystem aufsetzen ==== 
- +  * Lassen ​Sie den produktiven IdP 2.x zunächst unverändert weiter laufen. 
-  * lassen ​Sie den produktiven IdP 2.x zunächst unverändert weiter laufen +  * Installieren ​Sie den aktuellsten ​IdP 3.4.x auf einem (neuen) Testsystem von Grund auf wie in diesem Wiki beschrieben.
-  * 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:   * 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. +    * Konfigurieren ​Sie ''​attribut-resolver.xml'' ​und ''​attribut-filter.xml'' ​analog zu Ihrem IdP 2.x und überzeugen Sie sich mithilfe unserer Test-SPsdass 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. +    * **Bitte bauen Sie in diesem Zuge auch die Syntax von ''​attribute-resolver.xml''​ um!** Die Syntax von Shibboleth IdP 2.x mit den zahlreichen Namespaces wird ab Shibboleth 4.x nicht mehr unterstützt. Hiermit legen Sie eine wichtige Grundlage für das Upgrade auf die 4er-Version. Beispiele finden Sie in der mitgelieferten Datei ''​conf/​attribute-resolver.xml''​ bzw. [[de:​attribute-resolver-example|hier im Wiki]]. 
-    * achten ​Sie hierbei darauf, dass Quellattribut(e) und Salt gleich bleiben! +    * Übrigens gibt es in der DFN-AAI keine SPs mehr, die ausschließlich den veralteten SAML1-Standard sprechen. Daher können Sie aus der ''​conf/​attribute-resolver.xml''​ alle **SAML1-Direktiven entfernen**.<​file xml ./​conf/​attribute-resolver.xml>​ 
-  * 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! +<​AttributeEncoder xsi:​type="​SAML1String"​ name="​urn:​mace:​dir:​attribute-def:​mail"​ encodeType="​false"​ /></​file>​Die SAML2-Encodings brauchen Sie selbstverständlich noch! 
-    * die entityID des IdP 3.x entspricht damit der des IdP 2.x +    * **Migrieren ​Sie die bestehende persistentId-Datenbank** vom IdP 2.x auf die Testinstallation und verifizieren Sie, dass die IDs unverändert geblieben sind. Achten ​Sie hierbei darauf, dass Quellattribut(e) und Salt gleich bleiben! ​**Die persistentIds müssen unverändert bleiben, damit Ihre Nutzer*innen bei den Service Providern wiedererkannt werden!** 
-    * die Kommunikations-URLs in den Metadaten bleiben unverändert +  * Wir empfehlen Ihnen, diesen Test-IdP zu behalten. So haben Sie für künftige Upgrades ein funktionierendes Testsystem, das Sie bei Bedarf einfach wieder in die Testföderation aufnehmen können. 
-    * ersetzen ​Sie auf dem IdP 3.x private-Key- und Zertifikatsdatei ​durch die entsprechenden Dateien vom IdP 2.x +==== Schritt 2: Neues Produktivsystem vorbereiten ==== 
-  * 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! +  * **Installieren ​Sie den IdP 3.4.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 auf Ihrem bestehenden ​2.x-System! 
-  * Übernehmen Sie die Attribute-, NameID-, Datenbank- und sonstige Konfigurationen von Ihrer 3.x Testinstallation auf das neue Produktiv-System. +    * Die entityID des IdP 3.4.x entspricht damit der des IdP 2.x. 
-  * ersetzen ​Sie in Ihrem DNS-Server die IP des alten IdP 2.x durch die IP des neuen IdP 3.x. +    * Die Kommunikations-URLs in den Metadaten bleiben unverändert. 
-  * lassen ​Sie den IdP 2.x noch so lange laufen, bis sich die DNS-Änderung weltweit verbreitet hat. +    * Ersetzen ​Sie auf dem IdP 3.4.x die automatisch generierten ​private-Key- und Zertifikatsdateien ​durch die entsprechenden Dateien vom IdP 2.x ([[de:​shibidp3config-zertifikate|Dokumentation]] zu ''​conf/​idp.properties''​). 
-  * wenn Sie sehen, dass am IdP 2.x keine Zugriffe mehr erfolgen, können Sie ihn abschalten.+  * Die Metadaten des IdP 3.4.x sind jetzt identisch zum IdP 2.x. Es muss nichts ​in der DFN-AAI-Metadatenverwaltung  ​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.4.x Testinstallation auf das neue Produktiv-System. 
 +==== Schritt 3: DNS-Eintrag schwenken ==== 
 +  * Ersetzen ​Sie in Ihrem DNS-Server die IP des alten IdP 2.x durch die IP des neuen IdP 3.4.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.
 (Siehe hierzu auch [[https://​download.aai.dfn.de/​ws/​2016_fub/​2016-06-17_Migrationsstrategien.pdf|diese Präsentation]]) (Siehe hierzu auch [[https://​download.aai.dfn.de/​ws/​2016_fub/​2016-06-17_Migrationsstrategien.pdf|diese Präsentation]])
  
-==== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie ====+===== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie ​=====
  
-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]]. \\ +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]]. 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 [[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.+Für den Fall, dass die deutsche Übersetzung danach fehlt, stellen Sie sicher, dass die [[de:shibidp3i18n|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 ====+===== Überblick über die Konfigurationsänderungen ab IdP v3.4.0 - Vorbereitung auf IdP v4.x =====
  
 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)]]. 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 ===+==== conf/​idp.properties ​====
   - Sicherstellen,​ dass ''​idp.cookie.secure = true''​ gesetzt ist (es sei denn, es soll explizit nicht so sein):<​code>​   - Sicherstellen,​ dass ''​idp.cookie.secure = true''​ gesetzt ist (es sei denn, es soll explizit nicht so sein):<​code>​
 idp.cookie.secure = true idp.cookie.secure = true
Zeile 42: Zeile 49:
 </​code>​ </​code>​
   - Änderung der folgenden zwei Direktiven:   - Änderung der folgenden zwei Direktiven:
-    * ''​idp.consent.userStorageKey''​ ersetzen durch ''​idp.consent.attribute-release.userStorageKey''​ +    * ''​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''<​file xml conf/​idp.properties>​+    * ''​idp.consent.userStorageKeyAttribute''​ ersetzen durch ''​idp.consent.attribute-release.userStorageKeyAttribute''​ und ''​idp.consent.terms-of-use.userStorageKeyAttribute''<​file xml conf/​idp.properties>​
 # Beispiel: # Beispiel:
 [...] [...]
Zeile 53: Zeile 60:
 </​file>​ </​file>​
  
-=== conf/​c14n/​subject-c14n.xml ===+==== conf/​c14n/​subject-c14n.xml ​====
 Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert):​ Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert):​
 <file xml conf/​c14n/​subject-c14n.xml>​ <file xml conf/​c14n/​subject-c14n.xml>​
Zeile 66: Zeile 73:
 </​file>​ </​file>​
  
-=== conf/​attribute-resolver.xml ===+==== conf/​attribute-resolver.xml ​====
   - Im Attribute Resolver wird die ''​Dependency''​-Direktive ersetzt.   - Im Attribute Resolver wird die ''​Dependency''​-Direktive ersetzt.
     * Wenn die Dependency sich auf einen 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>​     * Wenn die Dependency sich auf einen 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>​
Zeile 114: Zeile 121:
 </​file>​ </​file>​
  
-=== metadata/​idp-metadata.xml mit Ablaufdatum ===+==== 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>​ 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"?>​ <?xml version="​1.0"​ encoding="​UTF-8"?>​
Zeile 128: Zeile 135:
 </​file>​ </​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''​)
 +  * Kopieren der Catalina/​localhost-Config zu Tomcat9
 +  * "/​usr/​share/​java/"​ zu ''/​etc/​tomcat9/​catalina.properties''​ hinzufügen
 +  * 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
  • Zuletzt geändert: vor 3 Monaten