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
de:shibidp3upgrade [2019/04/02 09:56] – [Überblick über die nötigen Konfigurationsänderungen in Vorbereitung auf IdP v4.x] Silke Meyerde:shibidp3upgrade [2022/05/02 15:39] (aktuell) – Archiv-Tag Silke Meyer
Zeile 1: Zeile 1:
-======Upgrade======+~~NOTOC~~ 
 +======Upgrade von IdP 3.x====== 
 +{{INLINETOC 2}}
  
-==== Migration 2.x --> 3.x ==== 
  
-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.+===== Hinweise zum Upgrade innerhalb der IdP v3 Produktlinie =====
  
-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://wiki.shibboleth.net/confluence/display/IDP30/Upgrading. Etwas ausführlicher ist die Anleitung von [[https://www.switch.ch/aai/guides/idp/installation/#keepinguptodate|SWITCH]]. \\ 
- +
-  * 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, 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. +
-    * 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, 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! +
-    * 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://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]]. \\ +
  
 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]]. 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]].
  
-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.+Für den Fall, dass die deutsche Übersetzung danach fehlt, stellen Sie sicher, dass die [[de:shibidp:config-i18n|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 ===== 
-Englischsprachige Quelle im offiziellen Shibboleth-Wiki: https://wiki.shibboleth.net/confluence/display/IDP30/DeprecatedIdPV4 +<callout color="#ff9900" title="Wichtiger Hinweis"> 
 +Als Voraussetzung für ein erfolgreiches Upgrade auf Version 4.x sollte zuvor mindestens die Version Shib IdP 3.4.6, installiert worden sein. Siehe hierzu im Shibboleth Wiki unter https://wiki.shibboleth.net/confluence/display/IDP4/Upgrading 
 +</callout> 
 +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)]].
  
-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://wiki.shibboleth.net/confluence/display/IDP30/ReleaseNotes#ReleaseNotes-3.4.0(October10,2018) | Release Notes]] sei auf das Shibboleth-Wiki verwiesen. +==== conf/idp.properties ====
- +
-=== conf/idp.properties ===+
   - Sicherstellen, dass ''idp.cookie.secure = true'' gesetzt ist (es sei denn, es soll explizit nicht so sein):<code>   - Sicherstellen, dass ''idp.cookie.secure = true'' gesetzt ist (es sei denn, es soll explizit nicht so sein):<code>
 idp.cookie.secure = true idp.cookie.secure = true
Zeile 42: Zeile 24:
 </code> </code>
   - Änderung der folgenden zwei Direktiven:   - Ä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''<code> +    * ''idp.consent.userStorageKeyAttribute'' ersetzen durch ''idp.consent.attribute-release.userStorageKeyAttribute'' und ''idp.consent.terms-of-use.userStorageKeyAttribute''<file xml conf/idp.properties> 
-    * # Beispiel:+# 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/c14n/subject-c14n.xml ===+==== conf/c14n/subject-c14n.xml ====
 Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert): Der LegacyPrincipalConnector wird entfernt (oder zumindest auskommentiert):
 <file xml conf/c14n/subject-c14n.xml> <file xml conf/c14n/subject-c14n.xml>
-        <!-- +[...] 
-        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 +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. 
-        remove this. +--> 
-        --> +<!-- <ref bean="c14n/LegacyPrincipalConnector" /> --> 
-        <!-- <ref bean="c14n/LegacyPrincipalConnector" /> -->+[...]
 </file> </file>
  
-=== conf/attribute-resolver.xml (ab 3.4.2) ===+==== 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.4.1: +# bis IdP v3.3.x: 
-    <AttributeDefinition xsi:type="Simple" id="mail" sourceAttributeID="mail">+    [...] 
 +    <AttributeDefinition id="mail" xsi:type="Simple" sourceAttributeID="mail">
         <Dependency ref="myLDAP" />         <Dependency ref="myLDAP" />
             <DisplayName xml:lang="en">E-mail</DisplayName>             <DisplayName xml:lang="en">E-mail</DisplayName>
Zeile 74: Zeile 59:
         <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />         <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false" />
     </AttributeDefinition>     </AttributeDefinition>
 +    [...]
  
-# ab IdP v3.4.2: +# ab IdP v3.4.x: 
-    <AttributeDefinition xsi:type="Simple" id="mail">+    [...] 
 +    <AttributeDefinition id="mail" xsi:type="Simple">
         <InputDataConnector ref="myLDAP" attributeNames="mail"/>         <InputDataConnector ref="myLDAP" attributeNames="mail"/>
         <DisplayName xml:lang="en">E-mail</DisplayName>         <DisplayName xml:lang="en">E-mail</DisplayName>
Zeile 84: Zeile 71:
         <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false"/>         <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.3" friendlyName="mail" encodeType="false"/>
     </AttributeDefinition>     </AttributeDefinition>
 +    [...]
 </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"> 
 +        <DisplayName xml:lang="en">User Name</DisplayName> 
 +        <DisplayName xml:lang="de">Nutzerkennung</DisplayName> 
 +        <DisplayDescription xml:lang="en">Local User Id</DisplayDescription> 
 +        <DisplayDescription xml:lang="de">Nutzerkennung der Heimateinrichtung</DisplayDescription> 
 +        <AttributeEncoder xsi:type="SAML2String" name="urn:oid:0.9.2342.19200300.100.1.1" friendlyName="uid" encodeType="false"/> 
 +    </AttributeDefinition> 
     <AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" scope="%{idp.scope}">     <AttributeDefinition id="eduPersonPrincipalName" xsi:type="Scoped" scope="%{idp.scope}">
         <InputAttributeDefinition ref="uid" />         <InputAttributeDefinition ref="uid" />
Zeile 94: Zeile 91:
         <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" encodeType="false" />         <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" encodeType="false" />
     </AttributeDefinition>     </AttributeDefinition>
 +    [...]
 </file> </file>
 +    * **Abhängigkeiten in Data Connectors** müssen nach demselben Prinzip angepasst werden:<file xml conf/attribute-resolver.xml>
 +    <DataConnector id="StoredId" xsi:type="StoredId"
 +        generatedAttributeID="persistentID"
 +        salt="%{idp.persistentId.salt}"
 +        queryTimeout="0">
 +        <InputDataConnector ref="myLDAP" attributeNames="%{idp.persistentId.sourceAttribute}"/>
 +        <BeanManagedConnection>shibboleth.MySQLDataSource</BeanManagedConnection>
 +    </DataConnector></file>
 +
 +==== 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"?>
 +<!--
 +     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.
 +-->
 +<EntityDescriptor  xmlns="urn:oasis:names:tc:SAML:2.0:metadata" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:shibmd="urn:mace:shibboleth:metadata:1.0" xmlns:xml="http://www.w3.org/XML/1998/namespace" xmlns:mdui="urn:oasis:names:tc:SAML:metadata:ui" xmlns:req-attr="urn:oasis:names:tc:SAML:protocol:ext:req-attr" validUntil="2019-05-22T11:01:10.621Z" entityID="https://localhost.localdomain/idp/shibboleth">
 +
 +[...]
 +</file>
 +
 +==== conf/ldap.properties ====
 +Folgende Zeile muss in den LDAP-Einstellungen ab Shibboleth 3.4.4 aktualisiert werden, falls vorhanden:
 +<file xml conf/ldap.properties>
 +# 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)
 +</file>
 +
 +===== 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, libmariadb-java, libtaglibs-standard-impl-java, default-libmysqlclient-dev bzw. libmariadb-dev)
 +  * 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
 +  * "/usr/share/java/" zu ''/etc/tomcat9/catalina.properties'' hinzufügen (common.loader)
 +  * Anpassen der /etc/default/tomcat9
 +  * systemctl edit tomcat9:<code>
 +[Unit]
 +After=mariadb.service
 +Wants=mariadb.service
 +[Service]
 +ReadWritePaths=/opt/shibboleth-idp/logs/
 +ReadWritePaths=/opt/shibboleth-idp/metadata/</code>
 +  * Shibboleth-IdP neu bauen (bin/build.sh)
 +  * falls nötig: [[https://doku.tid.dfn.de/de:shibidp3config-idm#java-version|LDAP-Workaround aktivieren]]
 +  * Anpassen der Berechtigungen von User/Gruppe ''tomcat8'' zu ''tomcat''
 +  * Deinstallation alter Pakete
 +
 +{{tag>archiv}}
  • Zuletzt geändert: vor 5 Jahren