====== IdP-Migration ======
		 
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 =====
  * Lassen Sie den produktiven IdP zunächst unverändert weiter laufen.	 
  * 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:
    * Wenn es Software-Versionunterschiede zwischen dem alten und dem neuen IdP gibt, prüfen Sie z.B. anhand der Release Notes, ob Sie  Konfigurationsdateien aus dem alten IdP so übernehmen können.
    * 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 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.
      * Suchen Sie sich für eine Stichprobe einen SP aus der Datenbanktabelle ''shibpid'' aus, z.B. testsp3.aai.dfn.de.
      * Suchen Sie dann einen PrincipalName aus, der für diesen SP schon eine persistentId in der Datenbank hat.
      * Dort setzen Sie localEntity auf die EntityID Ihres Test-IdPs.
      * 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.	 

===== Schritt 2: Neues Produktivsystem vorbereiten =====
  * **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 neuen IdP entspricht damit der des alten IdP.**	 
    * Die Kommunikations-URLs in den Metadaten bleiben unverändert.	 
    * 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 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 Testinstallation auf das neue Produktiv-System.
	 
===== Schritt 3: DNS-Eintrag schwenken =====
  * Ersetzen Sie in Ihrem DNS-Server die IP-Adresse(n) des alten IdP durch die des neuen IdP.	 
  * Lassen Sie den alten IdP noch so lange laufen, bis sich die DNS-Änderung weltweit verbreitet hat.	 
  * Wenn Sie sehen, dass am alten IdP keine Zugriffe mehr erfolgen, können Sie ihn abschalten.

{{tag>migration}}