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:

  • 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 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: 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. 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.
  • 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 (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.
  • 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.
  • Zuletzt geändert: vor 2 Jahren