Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende Überarbeitung Nächste ÜberarbeitungBeide Seiten der Revision | ||
de:shibidp3upgrade [2020/05/22 12:22] – [Überblick über die Konfigurationsänderungen ab IdP v3.4.0 - Vorbereitung auf IdP v4.x] Wolfgang Pempe | de:shibidp3upgrade [2021/02/17 13:50] – [conf/attribute-resolver.xml] Silke Meyer | ||
---|---|---|---|
Zeile 14: | Zeile 14: | ||
===== Überblick über die Konfigurationsänderungen ab IdP v3.4.0 - Vorbereitung auf IdP v4.x ===== | ===== Überblick über die Konfigurationsänderungen ab IdP v3.4.0 - Vorbereitung auf IdP v4.x ===== | ||
<callout color="# | <callout color="# | ||
- | Als Voraussetzung für ein erfolgreiches Upgrade auf Version 4.x sollte zuvor die letzte | + | Als Voraussetzung für ein erfolgreiches Upgrade auf Version 4.x sollte zuvor mindestens |
</ | </ | ||
Ab IdP v3.4.0 werden Konfigurationsparameter als veraltet geloggt, die in Version 4.x nicht mehr vorkommen werden. An dieser Stelle sammeln wir fortlaufend die wichtigsten Änderungen. Das erklärte Ziel der Shibboleth-Entwickler*innen ist es, dass eine mitgepflegte Konfiguration nach einem Upgrade auf IdP v4.x fehlerfrei startet. Die jeweiligen vollständigen [[https:// | Ab IdP v3.4.0 werden Konfigurationsparameter als veraltet geloggt, die in Version 4.x nicht mehr vorkommen werden. An dieser Stelle sammeln wir fortlaufend die wichtigsten Änderungen. Das erklärte Ziel der Shibboleth-Entwickler*innen ist es, dass eine mitgepflegte Konfiguration nach einem Upgrade auf IdP v4.x fehlerfrei startet. Die jeweiligen vollständigen [[https:// | ||
Zeile 48: | Zeile 48: | ||
==== conf/ | ==== conf/ | ||
- Im Attribute Resolver wird die '' | - Im Attribute Resolver wird die '' | ||
- | * Wenn die Dependency sich auf einen Data Connector bezieht, wird ab IdP v3.4.2 stattdessen '' | + | |
# bis IdP v3.3.x: | # bis IdP v3.3.x: | ||
[...] | [...] | ||
Zeile 73: | Zeile 73: | ||
[...] | [...] | ||
</ | </ | ||
- | * Wenn die Dependency sich auf ein anderes Attribut bezieht, das in conf/ | + | |
[...] | [...] | ||
< | < | ||
Zeile 93: | Zeile 93: | ||
[...] | [...] | ||
</ | </ | ||
+ | Abhängigkeiten in Data Connectors müssen nach demselben Prinzip angepasst werden:< | ||
+ | < | ||
+ | generatedAttributeID=" | ||
+ | salt=" | ||
+ | queryTimeout=" | ||
+ | < | ||
+ | < | ||
+ | </ | ||
==== metadata/ | ==== metadata/ | ||
Zeile 124: | Zeile 132: | ||
* Installation der neuen Pakete (tomcat9, mariadb-server, | * Installation der neuen Pakete (tomcat9, mariadb-server, | ||
* Anpassen der Default-Java-Version ('' | * Anpassen der Default-Java-Version ('' | ||
+ | * Prüfen der [[de: | ||
* Kopieren der Catalina/ | * Kopieren der Catalina/ | ||
- | * "/ | + | * "/ |
* Anpassen der / | * Anpassen der / | ||
* systemctl edit tomcat9:< | * systemctl edit tomcat9:< | ||
Zeile 138: | Zeile 147: | ||
* Anpassen der Berechtigungen von User/Gruppe '' | * Anpassen der Berechtigungen von User/Gruppe '' | ||
* Deinstallation alter Pakete | * Deinstallation alter Pakete | ||
- | |||
- | ===== Alt: Migration von IdP 2.x auf 3.4.x ===== | ||
- | |||
- | Ein [[https:// | ||
- | |||
- | Um Ihren IdP 2.x in der DFN-AAI ohne Downtime auf 3.4.x zu migrieren, empfehlen wir daher folgende Vorgehensweise, | ||
- | |||
- | ==== Schritt 1: Testsystem aufsetzen ==== | ||
- | * Lassen Sie den produktiven IdP 2.x zunächst unverändert weiter laufen. | ||
- | * Installieren Sie den aktuellsten IdP 3.4.x auf einem (neuen) Testsystem von Grund auf wie in diesem Wiki beschrieben. | ||
- | * Testen Sie damit ausführlich in der DFN-AAI-Test, | ||
- | * Konfigurieren Sie '' | ||
- | * **Bitte bauen Sie in diesem Zuge auch die Syntax von '' | ||
- | * Übrigens gibt es in der DFN-AAI keine SPs mehr, die ausschließlich den veralteten SAML1-Standard sprechen. Daher können Sie aus der '' | ||
- | < | ||
- | * **Migrieren Sie die bestehende persistentId-Datenbank** vom IdP 2.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!** | ||
- | * 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 IdP 3.4.x so auf einem neuen Produktivsystem, | ||
- | * Die entityID des IdP 3.4.x entspricht damit der des IdP 2.x. | ||
- | * Die Kommunikations-URLs in den Metadaten bleiben unverändert. | ||
- | * Ersetzen Sie auf dem IdP 3.4.x die automatisch generierten private-Key- und Zertifikatsdateien durch die entsprechenden Dateien vom IdP 2.x ([[de: | ||
- | * Die Metadaten des IdP 3.4.x sind jetzt identisch zum IdP 2.x. Es muss nichts in der DFN-AAI-Metadatenverwaltung | ||
- | * Übernehmen Sie die Attribute-, NameID-, Datenbank- und sonstige Konfigurationen von Ihrer 3.4.x Testinstallation auf das neue Produktiv-System. | ||
- | ==== Schritt 3: DNS-Eintrag schwenken ==== | ||
- | * Ersetzen Sie in Ihrem DNS-Server die IP des alten IdP 2.x durch die IP des neuen IdP 3.4.x. | ||
- | * Lassen Sie den IdP 2.x noch so lange laufen, bis sich die DNS-Änderung weltweit verbreitet hat. | ||
- | * Wenn Sie sehen, dass am IdP 2.x keine Zugriffe mehr erfolgen, können Sie ihn abschalten. | ||
- | (Siehe hierzu auch [[https:// | ||
{{tag> | {{tag> |