Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:shibidp3upgrade [2019/05/22 13:06] – [Überblick über die Konfigurationsänderungen ab IdP v3.4.0 - Vorbereitung auf IdP v4.x] Silke Meyer
+++ de:shibidp3upgrade [2019/08/19 13:27] – Silke Meyer
@@ Zeile 1: / Zeile 1: @@
+~~NOTOC~~
 ======Upgrade======
+{{INLINETOC 2}}
+===== Migration von IdP 2.x auf 3.4.x =====
-==== Migration 2.x --> 3.x ====
+Ein [[https://wiki.shibboleth.net/confluence/display/IDP30/UpgradingFromV2|Upgrade von IdP Version 2.x auf 3.4.x]] auf ein und demselben Host wird von den Entwicklern nicht empfohlen, da sich die Konfigurationen zu sehr unterscheiden und es keine automatische Konvertierung gibt.
-Ein [[https://wiki.shibboleth.net/confluence/display/IDP30/UpgradingFromV2|Upgrade von IdP Version 2.x auf 3.x]] auf ein und demselben Host wird von den Entwicklern nicht empfohlen, da sich die Konfigurationen zu sehr unterscheiden und es keine automatische Konvertierung gibt.
+Um Ihren IdP 2.x in der DFN-AAI ohne Downtime auf 3.4.x zu migrieren, empfehlen wir daher folgende Vorgehensweise, in der beide IdP-Versionen während der Migration parallel betrieben werden:
-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:
+==== Schritt 1: Testsystem aufsetzen ====
+  * Lassen Sie den produktiven IdP 2.x zunächst unverändert weiter laufen.
-  * 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.
-  * 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, bis Sie gut mit der Konfiguration vertraut sind:
-    * 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.
+    * Konfigurieren Sie ''attribut-resolver.xml'' und ''attribut-filter.xml'' 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.
+    * **Bitte bauen Sie in diesem Zuge auch die Syntax von ''attribute-resolver.xml'' um!** Die Syntax von Shibboleth IdP 2.x mit den zahlreichen Namespaces wird ab Shibboleth 4.x nicht mehr unterstützt. Hiermit legen Sie eine wichtige Grundlage für das Upgrade auf die 4er-Version. Beispiele finden Sie in der mitgelieferten Datei ''conf/attribute-resolver.xml'' bzw. [[de:attribute-resolver-example|hier im Wiki]].
-  * installieren Sie den IdP 3.x so auf einem neuen Produktivsystem, dass die Metadaten identisch zu Ihrem IdP 2.x sind, indem Sie bei der Installation den gleichen DNS-Namen wählen wie ihr bestehendes 2.x-System!
+    * Übrigens gibt es in der DFN-AAI keine SPs mehr, die ausschließlich den veralteten SAML1-Standard sprechen. Daher können Sie aus der ''conf/attribute-resolver.xml'' alle **SAML1-Direktiven entfernen**.<file xml ./conf/attribute-resolver.xml>
-    * die entityID des IdP 3.x entspricht damit der des IdP 2.x
+<AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" /></file>Die SAML2-Encodings brauchen Sie selbstverständlich noch!
-    * die Kommunikations-URLs in den Metadaten bleiben unverändert
+    * **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!**
-    * ersetzen Sie auf dem IdP 3.x private-Key- und Zertifikatsdatei durch die entsprechenden Dateien vom IdP 2.x
+  * 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.
-  * 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!
+==== Schritt 2: Neues Produktivsystem vorbereiten ====
-  * Übernehmen Sie die Attribute-, NameID-, Datenbank- und sonstige Konfigurationen von Ihrer 3.x Testinstallation auf das neue Produktiv-System.
+  * **Installieren Sie den IdP 3.4.x so auf einem neuen Produktivsystem, dass die Metadaten identisch zu Ihrem IdP 2.x sind**, indem Sie bei der Installation den gleichen DNS-Namen wählen wie auf Ihrem bestehenden 2.x-System!
-  * ersetzen Sie in Ihrem DNS-Server die IP des alten IdP 2.x durch die IP des neuen IdP 3.x.
+    * Die entityID des IdP 3.4.x entspricht damit der des IdP 2.x.
-  * lassen Sie den IdP 2.x noch so lange laufen, bis sich die DNS-Änderung weltweit verbreitet hat.
+    * Die Kommunikations-URLs in den Metadaten bleiben unverändert.
-  * wenn Sie sehen, dass am IdP 2.x keine Zugriffe mehr erfolgen, können Sie ihn abschalten.
+    * Ersetzen Sie auf dem IdP 3.4.x die automatisch generierten private-Key- und Zertifikatsdateien durch die entsprechenden Dateien vom IdP 2.x ([[de:shibidp3config-zertifikate|Dokumentation]] zu ''conf/idp.properties'').
+  * Die Metadaten des IdP 3.4.x sind jetzt identisch zum IdP 2.x. 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 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://download.aai.dfn.de/ws/2016_fub/2016-06-17_Migrationsstrategien.pdf|diese Präsentation]])
-==== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie ====
+===== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie =====
-https://wiki.shibboleth.net/confluence/display/IDP30/Upgrading (erfolgreich getestet mit Upgrade von 3.1.1 auf 3.1.2). Etwas ausführlicher ist die Anleitung von [[https://www.switch.ch/aai/guides/idp/installation/#keepinguptodate|SWITCH]]. \\
+https://wiki.shibboleth.net/confluence/display/IDP30/Upgrading. Etwas ausführlicher ist die Anleitung von [[https://www.switch.ch/aai/guides/idp/installation/#keepinguptodate|SWITCH]]. \\
 Unter Linux ist insbesondere darauf zu achten, dass beim Upgrade die Schreib-/Leseberechtigungen korrekt gesetzt werden (Parameter'' -Didp.conf.filemode=644'' beim Aufruf von ''./bin/install.sh''). Siehe hierzu auch die Anleitung von SWITCH unter [[https://www.switch.ch/aai/guides/idp/installation/#upgrading|8.2. Common upgrade instructions for the Shibboleth IdP 3]].
@@ Zeile 31: / Zeile 39: @@
 Für den Fall, dass die deutsche Übersetzung danach fehlt, stellen Sie sicher, dass die [[https://wiki.shibboleth.net/confluence/display/IDP30/MessagesTranslation#MessagesTranslation-v3.3IdentityProvider3.3|Sprachdatei]] unter dem Pfad ''<installationspfad>/system/messages/messages_de.properties'' (meist: ''/opt/shibboleth-idp/system/messages/messages_de.properties'') liegt.
-==== Ü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 =====
 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://wiki.shibboleth.net/confluence/display/IDP30/ReleaseNotes#ReleaseNotes-3.4.0(October10,2018) | Release Notes]] sind wie immer im Shibboleth-Wiki. Dort finden Sie ebenfalls eine vollständige [[https://wiki.shibboleth.net/confluence/display/IDP30/DeprecatedIdPV4|Übersicht über abgekündigte Konfigurationsdirektiven (DeprecatedIdPV4)]].
-=== conf/idp.properties ===
+==== conf/idp.properties ====
   - Sicherstellen, dass ''idp.cookie.secure = true'' gesetzt ist (es sei denn, es soll explizit nicht so sein):<code>
 idp.cookie.secure = true
@@ Zeile 41: / Zeile 49: @@
 </code>
   - Änderung der folgenden zwei Direktiven:
-    * ''idp.consent.userStorageKey'' ersetzen durch ''idp.consent.attribute-release.userStorageKey''
+    * ''idp.consent.userStorageKey'' ersetzen durch ''idp.consent.attribute-release.userStorageKey'' und ''idp.consent.terms-of-use.userStorageKey''
-    * ''idp.consent.userStorageKeyAttribute'' ersetzen durch ''idp.consent.attribute-release.userStorageKeyAttribute''<file xml conf/idp.properties>
+    * ''idp.consent.userStorageKeyAttribute'' ersetzen durch ''idp.consent.attribute-release.userStorageKeyAttribute'' und ''idp.consent.terms-of-use.userStorageKeyAttribute''<file xml conf/idp.properties>
 # Beispiel:
 [...]
@@ Zeile 52: / Zeile 60: @@
 </file>
-=== conf/c14n/subject-c14n.xml ===
+==== conf/c14n/subject-c14n.xml ====
 Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert):
 <file xml conf/c14n/subject-c14n.xml>
@@ Zeile 65: / Zeile 73: @@
 </file>
-=== conf/attribute-resolver.xml ===
+==== conf/attribute-resolver.xml ====
   - Im Attribute Resolver wird die ''Dependency''-Direktive ersetzt.
     * Wenn die Dependency sich auf einen Data Connector bezieht, wird ab IdP v3.4.2 stattdessen ''InputDataConnector'' verwendet. Bei jedem InputDataConnector muss das zu holende Attribut mit ''attributeNames'' mit angegeben werden. Damit wird die ''sourceAttributeID'' ersetzt.<file xml conf/attribute-resolver.xml>
@@ Zeile 113: / Zeile 121: @@
 </file>
-=== metadata/idp-metadata.xml mit Ablaufdatum ===
+==== metadata/idp-metadata.xml mit Ablaufdatum ====
 Ab Shib IdP v3.4.x steht nach einer Neuinstallation ein Ablaufdatum in den IdP-Metadaten (metadata/idp-metadata.xml), das entfernt werden muss. Im folgenden Beispiel muss ''validUntil="2019-05-22T11:01:10.621Z"'' gelöscht werden.<file xml metadata/idp-metadata.xml>
 <?xml version="1.0" encoding="UTF-8"?>
@@ Zeile 125: / Zeile 133: @@
 [...]
+</file>
+==== conf/ldap.properties ====
+Folgende Zeile muss in den LDAP-Einstellungen aktualisiert werden, falls vorhanden:
+<file xml conf/ldap.properties>
+# alt:
+# idp.attribute.resolver.LDAP.searchFilter = (CN=$requestContext.principalName)
+# neu:
+idp.attribute.resolver.LDAP.searchFilter = (CN=$resolutionContext.principalName)
 </file>

archiv