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
Nächste ÜberarbeitungBeide Seiten der Revision
de:shibidp3upgrade [2020/10/12 14:12] – [Betriebssystem-Upgrade auf Debian 10] Silke Meyerde:shibidp3upgrade [2020/11/09 13:27] – [Betriebssystem-Upgrade auf Debian 10] Silke Meyer
Zeile 48: Zeile 48:
 ==== conf/attribute-resolver.xml ==== ==== conf/attribute-resolver.xml ====
   - Im Attribute Resolver wird die ''Dependency''-Direktive ersetzt.   - 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>+    * **Wenn die Dependency sich auf einen unten definierten 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>
 # bis IdP v3.3.x: # bis IdP v3.3.x:
     [...]     [...]
Zeile 73: Zeile 73:
     [...]     [...]
 </file> </file>
-    * Wenn die Dependency sich auf ein anderes Attribut bezieht, das in conf/attribute-resolver.xml definiert wird, wird stattdessen ''InputAttributeDefinition'' verwendet.<file xml conf/attribute-resolver.xml>+    * **Wenn die Dependency sich auf ein anderes, in dieser Datei definiertes Attribut bezieht**, das in conf/attribute-resolver.xml definiert wird, wird stattdessen ''InputAttributeDefinition'' verwendet.<file xml conf/attribute-resolver.xml>
     [...]     [...]
     <AttributeDefinition id="uid" xsi:type="PrincipalName">     <AttributeDefinition id="uid" xsi:type="PrincipalName">
Zeile 124: Zeile 124:
   * Installation der neuen Pakete (tomcat9, mariadb-server, libmariadb-java, libtaglibs-standard-impl-java, default-libmysqlclient-dev bzw. libmariadb-dev)   * Installation der neuen Pakete (tomcat9, mariadb-server, libmariadb-java, libtaglibs-standard-impl-java, default-libmysqlclient-dev bzw. libmariadb-dev)
   * Anpassen der Default-Java-Version (''update-alternatives --config java'')   * Anpassen der Default-Java-Version (''update-alternatives --config java'')
 +  * Prüfen der [[de:shibidp:prepare-tomcat|Tomcat-Konfiguration]]
   * Kopieren der Catalina/localhost-Config zu Tomcat9   * Kopieren der Catalina/localhost-Config zu Tomcat9
   * "/usr/share/java/" zu ''/etc/tomcat9/catalina.properties'' hinzufügen (common.loader)   * "/usr/share/java/" zu ''/etc/tomcat9/catalina.properties'' hinzufügen (common.loader)
Zeile 138: Zeile 139:
   * Anpassen der Berechtigungen von User/Gruppe ''tomcat8'' zu ''tomcat''   * Anpassen der Berechtigungen von User/Gruppe ''tomcat8'' zu ''tomcat''
   * Deinstallation alter Pakete   * Deinstallation alter Pakete
- 
-===== Alt: Migration von IdP 2.x auf 3.4.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. 
- 
-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: 
- 
-==== 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, bis Sie gut mit der Konfiguration vertraut sind: 
-    * 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. 
-    * **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]]. 
-    * Ü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> 
-<AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" /></file>Die SAML2-Encodings brauchen Sie selbstverständlich noch! 
-    * **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, 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! 
-    * 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: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]]) 
  
 {{tag>idp3 fixme}} {{tag>idp3 fixme}}
  • Zuletzt geändert: vor 2 Jahren