Zeige QuelltextÄltere VersionenLinks hierherNach oben Letzte ÄnderungenPer E-Mail sendenDruckenPermalink × Inhaltsverzeichnis IdP-Migration Schritt 1: Testsystem aufsetzen Schritt 2: Neues Produktivsystem vorbereiten Schritt 3: DNS-Eintrag schwenken 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 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. 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 (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. migration migration Zuletzt geändert: vor 24 Monaten Anmelden