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/10/08 10:14]
Wolfgang Pempe [Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie]
de:shibidp3upgrade [2020/07/02 08:34] (aktuell)
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 40: Zeile 13:
  
 ===== Ü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 =====
 +<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)]]. 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)]].
  
Zeile 64: Zeile 39:
 <file xml conf/​c14n/​subject-c14n.xml>​ <file xml conf/​c14n/​subject-c14n.xml>​
 [...] [...]
-        ​<!-- +<!-- 
-        This is installed to support the old mechanism of using PrincipalConnectors in the attribute resolver +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. 
-        ​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"​ /> -->
-        --> +
-        <!-- <ref bean="​c14n/​LegacyPrincipalConnector"​ /> -->+
 [...] [...]
 </​file>​ </​file>​
Zeile 165: Zeile 138:
   * Anpassen der Berechtigungen von User/Gruppe ''​tomcat8''​ zu ''​tomcat''​   * Anpassen der Berechtigungen von User/Gruppe ''​tomcat8''​ zu ''​tomcat''​
   * Deinstallation alter Pakete   * 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]])
 +
 +{{tag>​idp3 fixme}}
  • Zuletzt geändert: vor 9 Monaten