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/03/25 16:00] – [Deprecation Warnings 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.
  
-==== Deprecation Warnings in Vorbereitung auf IdP v4.x ====+===== Überblick über die Konfigurationsänderungen ab IdP v3.4.0 - Vorbereitung auf IdP v4.x ====
 +<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 ==== 
- +  Sicherstellen, dass ''idp.cookie.secure = true'' gesetzt ist (es sei dennes soll explizit nicht so sein):<code> 
-=== conf/idp.properties ==+idp.cookie.secure true 
- +[...] 
-Ersetzen der folgenden zwei Direktiven: +</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'' und ''idp.consent.terms-of-use.userStorageKeyAttribute''<file xml conf/idp.properties> 
-''idp.consent.userStorageKeyAttribute'' ersetzen durch ''idp.consent.attribute-release.userStorageKeyAttribute'' +Beispiel: 
- +[...]
-SIcherstellen, dass +
- +
-Beispiel: +
-<code>+
 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):
-<code+<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" /> --> +[...] 
-</code> +</file>
- +
-=== conf/attribute-resolver.xml (3.4.2) === +
-Statt ''Dependency'' und ''sourceAttributeID'' werden ''InputDataConnector'' und ''InputAttributeDefinition'' verwendet.+
  
-Vorher: +==== conf/attribute-resolver.xml ==== 
-<code+  - Im Attribute Resolver wird die ''Dependency''-Direktive ersetzt. 
-    <AttributeDefinition xsi:type="Simple" id="mail" sourceAttributeID="mail">+    * **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: 
 +    [...] 
 +    <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 75: Zeile 57:
             <DisplayDescription xml:lang="en">E-Mail address</DisplayDescription>             <DisplayDescription xml:lang="en">E-Mail address</DisplayDescription>
             <DisplayDescription xml:lang="de">E-Mail Adresse</DisplayDescription>             <DisplayDescription xml:lang="de">E-Mail Adresse</DisplayDescription>
-        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false" /> 
         <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>
-</code>+    [...]
  
-Nachher+# ab IdP v3.4.x
-<code>+    [...]
     <AttributeDefinition id="mail" xsi:type="Simple">     <AttributeDefinition id="mail" xsi:type="Simple">
         <InputDataConnector ref="myLDAP" attributeNames="mail"/>         <InputDataConnector ref="myLDAP" attributeNames="mail"/>
Zeile 88: Zeile 69:
         <DisplayDescription xml:lang="en">E-Mail address</DisplayDescription>         <DisplayDescription xml:lang="en">E-Mail address</DisplayDescription>
         <DisplayDescription xml:lang="de">E-Mail Adresse</DisplayDescription>         <DisplayDescription xml:lang="de">E-Mail Adresse</DisplayDescription>
-        <AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:mail" encodeType="false"/> 
         <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>
-</code>+    [...] 
 +</file> 
 +    * **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}"> 
 +        <InputAttributeDefinition ref="uid" /> 
 +        <DisplayName xml:lang="en">Principal name</DisplayName> 
 +        <DisplayName xml:lang="de">Netz-Id</DisplayName> 
 +        <DisplayDescription xml:lang="en">A unique identifier for a person, mainly for inter-institutional user identification</DisplayDescription> 
 +        <DisplayDescription xml:lang="de">Eindeutige, einrichtungsübergreifende Nutzerkennung</DisplayDescription> 
 +        <AttributeEncoder xsi:type="SAML2ScopedString" name="urn:oid:1.3.6.1.4.1.5923.1.1.1.6" friendlyName="eduPersonPrincipalName" encodeType="false" /> 
 +    </AttributeDefinition> 
 +    [...] 
 +</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