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 [2019/04/02 10:01] – [Überblick über die Konfigurationsänderungen ab IdP v3.4.0 - Vorbereitung auf IdP v4.x] Silke Meyer | de:shibidp3upgrade [2020/05/22 12:22] – [Überblick über die Konfigurationsänderungen ab IdP v3.4.0 - Vorbereitung auf IdP v4.x] Wolfgang Pempe | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
+ | ~~NOTOC~~ | ||
======Upgrade====== | ======Upgrade====== | ||
+ | {{INLINETOC 2}} | ||
- | ==== Migration 2.x --> 3.x ==== | ||
- | Ein [[https:// | + | ===== Hinweise zum Upgrade |
- | Um Ihren IdP 2.x in der DFN-AAI auf 3.x zu migrieren, empfehlen wir daher folgende Vorgehensweise in der beide IdP-Versionen während der Migration parallel betrieben werden: | + | https:// |
- | + | ||
- | * lassen Sie den produktiven IdP 2.x zunächst unverändert weiter laufen | + | |
- | * installieren Sie den IdP 3.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 attribut-resolver und attribut-filter analog zu Ihrem IdP 2.x und überzeugen Sie sich mithilfe unserer Test-SPs dass die Attribute so übermittelt werden, wie es Ihr IdP 2.x tut. | + | |
- | * migrieren Sie die bestehende persistentId-Datenbank vom IdP 2.x auf die Testinstallation und verifizieren Sie, dass die IDs unverändert geblieben sind. | + | |
- | * installieren Sie den IdP 3.x so auf einem neuen Produktivsystem, | + | |
- | * die entityID des IdP 3.x entspricht damit der des IdP 2.x | + | |
- | * die Kommunikations-URLs in den Metadaten bleiben unverändert | + | |
- | * ersetzen Sie auf dem IdP 3.x private-Key- und Zertifikatsdatei durch die entsprechenden Dateien vom IdP 2.x | + | |
- | * die Metadaten des IdP 3.x sind damit identisch zum IdP 2.x; es muss in der DFN-AAI-Metadatenregistrierung nichts eingetragen oder geändert werden. Insbesondere ist dort nach wie vor nur ein produktiver IdP eingetragen! | + | |
- | * Übernehmen Sie die Attribute-, NameID-, Datenbank- und sonstige Konfigurationen von Ihrer 3.x Testinstallation auf das neue Produktiv-System. | + | |
- | * ersetzen Sie in Ihrem DNS-Server die IP des alten IdP 2.x durch die IP des neuen IdP 3.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. | + | |
- | + | ||
- | + | ||
- | ==== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie ==== | + | |
- | + | ||
- | https:// | + | |
Unter Linux ist insbesondere darauf zu achten, dass beim Upgrade die Schreib-/ | Unter Linux ist insbesondere darauf zu achten, dass beim Upgrade die Schreib-/ | ||
- | Für den Fall, dass die deutsche Übersetzung danach fehlt, stellen Sie sicher, dass die [[https:// | + | Für den Fall, dass die deutsche Übersetzung danach fehlt, stellen Sie sicher, dass die [[de:shibidp3i18n|Sprachdatei]] unter dem Pfad ''< |
- | ==== Ü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 ===== |
- | Englischsprachige Quelle | + | <callout color="# |
+ | Als Voraussetzung für ein erfolgreiches Upgrade auf Version 4.x sollte zuvor die letzte Version der 3er-Produktlinie, | ||
+ | </ | ||
+ | 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 Änderungen. Für die vollständigen [[https:// | + | ==== conf/ |
- | + | ||
- | === conf/ | + | |
- Sicherstellen, | - Sicherstellen, | ||
idp.cookie.secure = true | idp.cookie.secure = true | ||
Zeile 42: | Zeile 24: | ||
</ | </ | ||
- Änderung der folgenden zwei Direktiven: | - Änderung der folgenden zwei Direktiven: | ||
- | * '' | + | * '' |
- | * '' | + | * '' |
- | | + | # Beispiel: |
+ | [...] | ||
idp.consent.attribute-release.userStorageKey = shibboleth.consent.PrincipalConsentStorageKey | idp.consent.attribute-release.userStorageKey = shibboleth.consent.PrincipalConsentStorageKey | ||
idp.consent.attribute-release.userStorageKeyAttribute = %{idp.persistentId.sourceAttribute} | idp.consent.attribute-release.userStorageKeyAttribute = %{idp.persistentId.sourceAttribute} | ||
idp.consent.terms-of-use.userStorageKey = shibboleth.consent.PrincipalConsentStorageKey | idp.consent.terms-of-use.userStorageKey = shibboleth.consent.PrincipalConsentStorageKey | ||
idp.consent.terms-of-use.userStorageKeyAttribute = %{idp.persistentId.sourceAttribute} | idp.consent.terms-of-use.userStorageKeyAttribute = %{idp.persistentId.sourceAttribute} | ||
- | </code> | + | [...] |
+ | </file> | ||
- | === conf/ | + | ==== conf/ |
Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert): | Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert): | ||
<file xml conf/ | <file xml conf/ | ||
- | | + | [...] |
- | This is installed to support the old mechanism of using PrincipalConnectors in the attribute resolver | + | <!-- |
- | | + | This is installed to support the old mechanism of using PrincipalConnectors in the attribute resolver to map SAML Subjects back into principals. If you don't use those (or this is a new install) you can remove this. |
- | | + | --> |
- | --> | + | <!-- <ref bean=" |
- | <!-- <ref bean=" | + | [...] |
</ | </ | ||
- | === 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 '' | * Wenn die Dependency sich auf einen Data Connector bezieht, wird ab IdP v3.4.2 stattdessen '' | ||
- | # bis IdP v3.4.1: | + | # bis IdP v3.3.x: |
+ | [...] | ||
< | < | ||
< | < | ||
Zeile 74: | Zeile 59: | ||
< | < | ||
</ | </ | ||
+ | [...] | ||
- | # ab IdP v3.4.2: | + | # ab IdP v3.4.x: |
+ | [...] | ||
< | < | ||
< | < | ||
Zeile 84: | Zeile 71: | ||
< | < | ||
</ | </ | ||
+ | [...] | ||
</ | </ | ||
* Wenn die Dependency sich auf ein anderes Attribut bezieht, das in conf/ | * Wenn die Dependency sich auf ein anderes Attribut bezieht, das in conf/ | ||
+ | [...] | ||
< | < | ||
< | < | ||
Zeile 102: | Zeile 91: | ||
< | < | ||
</ | </ | ||
+ | [...] | ||
</ | </ | ||
+ | |||
+ | ==== metadata/ | ||
+ | Ab Shib IdP v3.4.x steht nach einer Neuinstallation ein Ablaufdatum in den IdP-Metadaten (metadata/ | ||
+ | <?xml version=" | ||
+ | <!-- | ||
+ | This is example metadata only. Do *NOT* supply it as is without review, | ||
+ | and do *NOT* provide it in real time to your partners. | ||
+ | |||
+ | This metadata is not dynamic - it will not change as your configuration changes. | ||
+ | --> | ||
+ | < | ||
+ | |||
+ | [...] | ||
+ | </ | ||
+ | |||
+ | ==== conf/ | ||
+ | Folgende Zeile muss in den LDAP-Einstellungen ab Shibboleth 3.4.4 aktualisiert werden, falls vorhanden: | ||
+ | <file xml conf/ | ||
+ | # alt - mit dem Attribut CN als Suchfilter: | ||
+ | # idp.attribute.resolver.LDAP.searchFilter = (CN=$requestContext.principalName) | ||
+ | # neu - mit dem Attribut CN als Suchfilter: | ||
+ | idp.attribute.resolver.LDAP.searchFilter = (CN=$resolutionContext.principal) | ||
+ | </ | ||
+ | |||
+ | ===== Betriebssystem-Upgrade auf Debian 10 ===== | ||
+ | |||
+ | Debian 10 kommt mit Tomcat9 und Java 11. Das Upgrade besteht grob aus folgenden Schritten. Danke an den Kollegen aus Bremerhaven! | ||
+ | |||
+ | * System-Upgrade | ||
+ | * Installation der neuen Pakete (tomcat9, mariadb-server, | ||
+ | * Anpassen der Default-Java-Version ('' | ||
+ | * Kopieren der Catalina/ | ||
+ | * "/ | ||
+ | * Anpassen der / | ||
+ | * systemctl edit tomcat9:< | ||
+ | [Unit] | ||
+ | After=mariadb.service | ||
+ | Wants=mariadb.service | ||
+ | [Service] | ||
+ | ReadWritePaths=/ | ||
+ | ReadWritePaths=/ | ||
+ | * Shibboleth-IdP neu bauen (bin/ | ||
+ | * falls nötig: [[https:// | ||
+ | * Anpassen der Berechtigungen von User/Gruppe '' | ||
+ | * 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> |