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
Nächste ÜberarbeitungBeide Seiten der Revision
de:shibidp3upgrade [2019/08/19 13:28] – [conf/ldap.properties] Silke Meyerde:shibidp3upgrade [2020/03/10 13:08] Silke Meyer
Zeile 2: Zeile 2:
 ======Upgrade====== ======Upgrade======
 {{INLINETOC 2}} {{INLINETOC 2}}
-===== Migration von IdP 2.x auf 3.4.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. 
- 
-Um Ihren IdP 2.x in der DFN-AAI ohne Downtime auf 3.4.x zu migrieren, empfehlen wir daher folgende Vorgehensweise, in der beide IdP-Versionen während der Migration parallel betrieben werden: 
- 
-==== Schritt 1: Testsystem aufsetzen ==== 
-  * 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. 
-  * Testen Sie damit ausführlich in der DFN-AAI-Test, bis Sie gut mit der Konfiguration vertraut sind: 
-    * Konfigurieren Sie ''attribut-resolver.xml'' und ''attribut-filter.xml'' 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. 
-    * **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]]. 
-    * Ü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> 
-<AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" /></file>Die SAML2-Encodings brauchen Sie selbstverständlich noch! 
-    * **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!** 
-  * 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. 
-==== Schritt 2: Neues Produktivsystem vorbereiten ==== 
-  * **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! 
-    * Die entityID des IdP 3.4.x entspricht damit der des IdP 2.x. 
-    * Die Kommunikations-URLs in den Metadaten bleiben unverändert. 
-    * 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''). 
-  * 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]]) 
  
 ===== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie ===== ===== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie =====
Zeile 37: Zeile 10:
 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 =====
Zeile 138: Zeile 111:
 Folgende Zeile muss in den LDAP-Einstellungen ab Shibboleth 3.4.4 aktualisiert werden, falls vorhanden: Folgende Zeile muss in den LDAP-Einstellungen ab Shibboleth 3.4.4 aktualisiert werden, falls vorhanden:
 <file xml conf/ldap.properties> <file xml conf/ldap.properties>
-# alt:+# alt - mit dem Attribut CN als Suchfilter:
 # idp.attribute.resolver.LDAP.searchFilter = (CN=$requestContext.principalName) # idp.attribute.resolver.LDAP.searchFilter = (CN=$requestContext.principalName)
-# neu: +# neu - mit dem Attribut CN als Suchfilter
-idp.attribute.resolver.LDAP.searchFilter = (CN=$resolutionContext.principalName)+idp.attribute.resolver.LDAP.searchFilter = (CN=$resolutionContext.principal)
 </file> </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
 +
 +===== Alt: Migration von IdP 2.x auf 3.4.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.
 +
 +Um Ihren IdP 2.x in der DFN-AAI ohne Downtime auf 3.4.x zu migrieren, empfehlen wir daher folgende Vorgehensweise, in der beide IdP-Versionen während der Migration parallel betrieben werden:
 +
 +==== Schritt 1: Testsystem aufsetzen ====
 +  * 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.
 +  * Testen Sie damit ausführlich in der DFN-AAI-Test, bis Sie gut mit der Konfiguration vertraut sind:
 +    * Konfigurieren Sie ''attribut-resolver.xml'' und ''attribut-filter.xml'' 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.
 +    * **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]].
 +    * Ü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>
 +<AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" /></file>Die SAML2-Encodings brauchen Sie selbstverständlich noch!
 +    * **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!**
 +  * 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.
 +==== Schritt 2: Neues Produktivsystem vorbereiten ====
 +  * **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!
 +    * Die entityID des IdP 3.4.x entspricht damit der des IdP 2.x.
 +    * Die Kommunikations-URLs in den Metadaten bleiben unverändert.
 +    * 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'').
 +  * 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]])
  • Zuletzt geändert: vor 23 Monaten