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
Letzte ÜberarbeitungBeide Seiten der Revision
de:shibidp:migration [2020/10/20 15:36] – [Schritt 2: Neues Produktivsystem vorbereiten] Silke Meyerde:shibidp:migration [2021/04/29 13:07] – [Schritt 1: Testsystem aufsetzen] Präzisierung shibpid Silke Meyer
Zeile 11: Zeile 11:
     * 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.     * 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.     * Ü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: Entfernen Sie die SAML1-Zeilen. 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. 
-    * **Migrieren Sie die bestehende persistentId-Datenbank** vom IdP 3.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!**  +    * **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: 
 +      * 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.     * 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 =====
Zeile 22: Zeile 27:
   * Ü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 4.x Testinstallation auf das neue Produktiv-System.  
 ===== Schritt 3: DNS-Eintrag schwenken ===== ===== Schritt 3: DNS-Eintrag schwenken =====
-  * Ersetzen Sie in Ihrem DNS-Server die IP des alten IdP 3.x durch die IP des neuen IdP 4.x.  +  * Ersetzen Sie in Ihrem DNS-Server die IP-Adresse(n) des alten IdP 3.x durch die des neuen IdP 4.x.  
   * Lassen Sie den IdP 3.x noch so lange laufen, bis sich die DNS-Änderung weltweit verbreitet hat.     * Lassen Sie den IdP 3.x 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 IdP 3.x keine Zugriffe mehr erfolgen, können Sie ihn abschalten.
 +
 +{{tag>idp4 migration}}
  • Zuletzt geändert: vor 3 Jahren