Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
de:shibidp:migration [2021/04/29 13:07] – [Schritt 1: Testsystem aufsetzen] Präzisierung shibpid Silke Meyerde:shibidp:migration [2021/10/25 16:02] (aktuell) – Generische Migrationsanleitung statt 3.x -> 4.x Silke Meyer
Zeile 1: Zeile 1:
-====== Migration auf IdP 4.x ======+====== IdP-Migration ======
      
-Um einen IdP 3.x in der DFN-AAI ohne Downtime auf 4.x zu migrieren, empfehlen wir folgende Vorgehensweise, in der beide IdP-Versionen während der Migration parallel betrieben werden:+Um einen IdP in der DFN-AAI ohne Downtime zu migrieren, empfehlen wir folgende Vorgehensweise, in der der alte und der neue IdP vorübergehend parallel betrieben werden - mit demselben Metadateneintrag:
  
 ===== Schritt 1: Testsystem aufsetzen ===== ===== Schritt 1: Testsystem aufsetzen =====
-  * Lassen Sie den produktiven IdP 3.x zunächst unverändert weiter laufen.  +  * Lassen Sie den produktiven IdP zunächst unverändert weiter laufen.  
-  * Installieren Sie den aktuellsten IdP 4.x auf einem (neuen) Testsystem von Grund auf wie in unserem [[de:shibidp:start|Tutorial]] beschrieben.  +  * Installieren Sie den aktuellsten IdP auf einem Testsystem von Grund auf wie in unserem [[de:shibidp:start|Tutorial]] 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:
-    * Kopieren Sie **keine** Konfigurationsdateien unbesehen aus dem alten IdP in den neuen IdP! Es haben sich diverse Standardeinstellungen oder Einstellungsmöglichkeiten geändert. +    * Wenn es Software-Versionunterschiede zwischen dem alten und dem neuen IdP gibt, prüfen Sie z.Banhand der Release Notes, ob Sie  Konfigurationsdateien aus dem alten IdP so übernehmen können.
-    * Übertragen Sie die definierten Attribute in die neue, abgespeckte ''conf/attribut-resolver.xml''Die Syntax der Datei hat sich gegenüber dem IdP 3.3.x stark verändert und ist seit dem IdP 3.4.x ausgedünnt worden. +
-    * Die Datei ''conf/attribut-filter.xml'' können Sie in den neuen IdP kopieren. Überzeugen Sie sich mithilfe unserer Test-SPs, dass die Attribute so übermittelt werden, wie es Ihr IdP 3.x tut. +
-    * Übertragen Sie die ''conf/relying-party.xml'' und prüfen Sie, welche der von Ihnen genutzten Service Provider den Algorithmus AES-GCM noch nicht unterstützen. Konfigurieren Sie für diese SPs Ausnahmen mit AES-CBC, wie in unserer [[de:shibidp:config-encryption|Dokumentation]] beschrieben.+
     * Bearbeiten Sie die Attribute in der Attribut Registry: [[de:shibidp:config-attributes#optionalsaml1_abschalten|Entfernen Sie die SAML1 Transcoder]]. SAML 1 wird in der DFN-AAI bald abgekündigt. Es gibt keine SPs mehr, die ausschließlich den veralteten SAML1-Standard sprechen. [[de:shibidp:config-attributes#vervollstaendigung_der_attribute_registry|Ergänzen Sie die Attribute Registry]] für den Einsatz in der DFN-AAI, falls Sie das während des Tutorials nicht schon getan haben.     * Bearbeiten Sie die Attribute in der Attribut Registry: [[de:shibidp:config-attributes#optionalsaml1_abschalten|Entfernen Sie die SAML1 Transcoder]]. SAML 1 wird in der DFN-AAI bald abgekündigt. Es gibt keine SPs mehr, die ausschließlich den veralteten SAML1-Standard sprechen. [[de:shibidp:config-attributes#vervollstaendigung_der_attribute_registry|Ergänzen Sie die Attribute Registry]] für den Einsatz in der DFN-AAI, falls Sie das während des Tutorials nicht schon getan haben.
-    * **Die persistentIds müssen unverändert bleiben, damit Ihre Nutzer*innen bei den Service Providern wiedererkannt werden! Migrieren Sie die bestehende persistentId-Datenbank** vom IdP 3.x auf die Testinstallation und **verifizieren Sie, dass die alten persistentIDs weiterverwendet statt neu generiert werden**. So gehen Sie auf einem Test-IdP vor:+    * **Die persistentIds müssen unverändert bleiben, damit Ihre Nutzer*innen bei den Service Providern wiedererkannt werden! Migrieren Sie die bestehende persistentId-Datenbank** vom alten IdP auf die Testinstallation und **verifizieren Sie, dass die alten persistentIDs weiterverwendet statt neu generiert werden**. So gehen Sie auf einem Test-IdP vor:
       * Achten Sie darauf, dass Quellattribut(e) (Datei ''conf/saml-nameid.properties'': ''idp.persistentId.sourceAttribute'') und Salt (Datei ''credentials/secrets.properties'': ''idp.persistentId.salt'') die gleichen sind wie auf dem alten IdP.       * Achten Sie darauf, dass Quellattribut(e) (Datei ''conf/saml-nameid.properties'': ''idp.persistentId.sourceAttribute'') und Salt (Datei ''credentials/secrets.properties'': ''idp.persistentId.salt'') die gleichen sind wie auf dem alten IdP.
       * Suchen Sie sich für eine Stichprobe einen SP aus der Datenbanktabelle ''shibpid'' aus, z.B. testsp3.aai.dfn.de.       * Suchen Sie sich für eine Stichprobe einen SP aus der Datenbanktabelle ''shibpid'' aus, z.B. testsp3.aai.dfn.de.
Zeile 19: Zeile 16:
       * Melden Sie sich an dem SP an und prüfen, ob die bereits in der Datenbank liegende persistentID übermittelt wird (idp-audit.log enthält den Wert). Wenn das nicht der Fall ist, sondern eine neue persistentId für den UserAccount und den SP generiert wurde, dann stimmt noch etwas nicht.       * Melden Sie sich an dem SP an und prüfen, ob die bereits in der Datenbank liegende persistentID übermittelt wird (idp-audit.log enthält den Wert). Wenn das nicht der Fall ist, sondern eine neue persistentId für den UserAccount und den SP generiert wurde, dann stimmt noch etwas nicht.
   * 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.     * 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 ===== ===== Schritt 2: Neues Produktivsystem vorbereiten =====
-  * **Installieren Sie den IdP 4.x so auf einem neuen Produktivsystem, dass die Metadaten identisch zu Ihrem IdP 3.x sind**, indem Sie bei der Installation den gleichen DNS-Namen wählen wie auf Ihrem bestehenden 3.x-System+  * **Installieren Sie den künftigen produktiven IdP so, dass die Metadaten identisch zu Ihrem alten IdP sind**, indem Sie bei der Installation den gleichen DNS-Namen wählen wie auf Ihrem alten IdP
-    * **Die entityID des IdP 4.x entspricht damit der des IdP 3.x.**  +    * **Die entityID des neuen IdP entspricht damit der des alten IdP.**  
     * Die Kommunikations-URLs in den Metadaten bleiben unverändert.       * Die Kommunikations-URLs in den Metadaten bleiben unverändert.  
-    * Ersetzen Sie auf dem IdP 4.x die automatisch generierten private-Key- und Zertifikatsdateien für die SAML-basierte Kommunikation durch die entsprechenden Dateien vom IdP 3.x ([[de:shibidp:config-zertifikate |Dokumentation]]).  +    * Ersetzen Sie auf dem neuen IdP die automatisch generierten private-Key- und Zertifikatsdateien für die SAML-basierte Kommunikation durch die entsprechenden Dateien vom alten IdP ([[de:shibidp:config-zertifikate |Dokumentation]]).  
-  * Die Metadaten des IdP 4.x sind jetzt identisch zum IdP 3.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!  +  * Die Metadaten des neuen IdP sind jetzt identisch zu denen des alten IdP. 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 Attribut-, NameID-, Datenbank- und sonstige Konfigurationen von Ihrer 4.x Testinstallation auf das neue Produktiv-System.  +  * Übernehmen Sie die Attribut-, NameID-, Datenbank- und sonstige Konfigurationen von Ihrer Testinstallation auf das neue Produktiv-System. 
 +  
 ===== Schritt 3: DNS-Eintrag schwenken ===== ===== Schritt 3: DNS-Eintrag schwenken =====
-  * Ersetzen Sie in Ihrem DNS-Server die IP-Adresse(n) des alten IdP 3.x durch die des neuen IdP 4.x.  +  * Ersetzen Sie in Ihrem DNS-Server die IP-Adresse(n) des alten IdP durch die des neuen IdP.  
-  * Lassen Sie den IdP 3.x noch so lange laufen, bis sich die DNS-Änderung weltweit verbreitet hat.  +  * Lassen Sie den alten IdP noch so lange laufen, bis sich die DNS-Änderung weltweit verbreitet hat.  
-  * Wenn Sie sehen, dass am IdP 3.x keine Zugriffe mehr erfolgen, können Sie ihn abschalten.+  * Wenn Sie sehen, dass am alten IdP keine Zugriffe mehr erfolgen, können Sie ihn abschalten.
  
-{{tag>idp4 migration}}+{{tag>migration}}
  • Zuletzt geändert: vor 2 Jahren