La migration vers l'IDP 4 est décrite par le consortium Shibboleth à l'adresse suivante :

• https://wiki.shibboleth.net/confluence/display/IDP4/Upgrading
• https://wiki.shibboleth.net/confluence/display/IDP4/SystemRequirements

Les informations présentées ici ne se substituent pas à la documentation upstream du consortium.

Elle décrit les opérations nécessaires pour effectuer la migration vers la version 4.0 de l'IDP - pour un IDP 3.4 installé comme décrit dans notre tutoriel.

Tout comme pour l'IDP 3.4, il existe un plugin disponible pour qu'un IDP 4.0 délègue l'authentification à un CAS. Le plugin ShibCaSAuthn d'Unicon a été porté pour l'IDP 4 sur https://github.com/Unicon/shib-cas-authn. Il convient de suivre “pas à pas” le guide d'installation du fichier README.md.

• Notes de versions, consortium Shibboleth

Outre les upgrades techniques (Spring 5…), les principales nouveautés fonctionnelles de l'IDP4 sont :

• Changement de l'algorithme de chiffrement par défaut : d'anciens SP peuvent ne pas le supporter. Lors d'une migration, la méthode de chiffrement n'est pas migrée vers le nouvel algorithme.
• SAML1.1 est désactivé par défaut
• Refonte de la gestion des attributs : la syntaxe 3.4 est toujours supportée et non dépréciée. Cependant, la nouvelle syntaxe apporte plus de lisibilité, de standardisation et de finesse de paramétrage dans le cas où l'IDP serait utilisé pour de multiples protocoles (SAML, CAS, OIDC…)
• API de métriques
• Baisse de la tolérance sur les metadata mal formées. Dans ce cas, le MetadataProvider concerné peut être complètement ignoré par l'IDP
• Possibilité de déléguer l'authentification à un autre IDP SAML
• Changement du connecteur LDAP : vous pouvez être impacté si vous avez modifié la configuration standard ldap-authn-config.xml

Pour rappel, ces configurations par défaut ne s'appliquent que pour une installation nouvelle, pas lors d'une mise à jour effectuée par le script d'installation, comme conseillé par les développeurs.

Nous vous invitons à faire une sauvegarde des informations de votre IDP, selon la méthode que vous préférez.

La première (et la plus fastidieuse) chose à faire avant de migrer est de mettre en conformité les fichiers de configuration de votre IDP. En effet, plusieurs paramètres ont été rendus obsolètes (mais toujours supportés en V3.4), et ne fonctionneront pas en V4.
Pour les repérer, le plus simple est de relancer votre IDP et de chercher les messages de ce type :

[...]
2020-09-21 14:59:40,038 -  - WARN [DEPRECATED:118] - xsi:type '{urn:mace:shibboleth:2.0:attribute:encoder}SAML1XMLObject', (file [/opt/shibboleth-idp/conf/attribute-resolver-ldap.xml]): This will be removed in the next major version of this software; replacement is {urn:mace:shibboleth:2.0:resolver}SAML1XMLObject
2020-09-21 14:59:40,039 -  - WARN [DEPRECATED:118] - xsi:type '{urn:mace:shibboleth:2.0:attribute:encoder}SAML2XMLObject', (file [/opt/shibboleth-idp/conf/attribute-resolver-ldap.xml]): This will be removed in the next major version of this software; replacement is {urn:mace:shibboleth:2.0:resolver}SAML2XMLObject
2020-09-21 14:59:40,040 -  - WARN [DEPRECATED:118] - xsi:type '{urn:mace:shibboleth:2.0:resolver:ad}SAML2NameID', (file [/opt/shibboleth-idp/conf/attribute-resolver-ldap.xml]): This will be removed in the next major version of this software; replacement is {urn:mace:shibboleth:2.0:resolver}SAML2NameID
[...]

La majeure partie des dépréciations sont liées à la résolution d'attribut. Il va donc vous falloir mettre à jour les fichiers en rapport.

Le tableau suivant donne les dépréciations pour un IDP 3.4 installé comme décrit dans le TP. En fonction de votre configuration, il se peut que d'autres dépréciations vous concernant ne soient pas listées.

Pour faciliter le travail, voici un header de fichier de résolution d'attribut d'où les headers dépréciés ont été enlevés. Vous pouvez commencer par remplacer votre header, et corriger les erreurs au fur et à mesure.

attribute-resolver.xml

<?xml version="1.0" encoding="UTF-8"?>
<AttributeResolver
        xmlns="urn:mace:shibboleth:2.0:resolver"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="urn:mace:shibboleth:2.0:resolver http://shibboleth.net/schema/idp/shibboleth-attribute-resolver.xsd">

Il s'agit au final d'une simplification, puisqu'un seul schéma XML est à présent nécessaire pour décrire la configuration de résolution d'attribut. Le nom du schéma urn:mace:shibboleth:2.0:resolver est le même qu'en V3, mais son contenu a été revu pour la V4.

Une fois vos fichiers de configuration à jour, de telle sorte que votre IDP ne loggue plus aucune erreur de dépréciation, vous pouvez passer à l'étape suivante.

Les balises <Dependency> permettant de définir la recherche d'un attribut dans un LDAP doivent être revus de la manière suivante :

v3

<resolver:AttributeDefinition id="mail"  xsi:type="ad:Simple" sourceAttributeID="mail">
  <resolver:Dependency ref="myLDAP" />
  [...]
</AttributeDefinition>

Devient :

v4

<AttributeDefinition id="mail" xsi:type="Simple">
    <InputDataConnector ref="myLDAP" attributeNames="mail" />
    [...]
</AttributeDefinition>

A présent que la configuration de votre IDP ne comporte plus de section dépréciée, il faut mettre en place les pré-requis :

• Java 11
• Jetty 9.4 ou Tomcat 9

Une fois les pré-requis en place, vérifiez le fonctionnement de votre IDP3. Pensez à bien vérifier notamment que c'est Java 11 qui est utilisé.

Téléchargez l'archive http://shibboleth.net/downloads/identity-provider/latest/shibboleth-identity-provider-4.0.1.tar.gz et décompressez-la.

Allez dans le dossier shibboleth-identity-provider-4.0.1/bin et lancez le script install.sh

$> cd shibboleth-identity-provider-4.0.1/bin
$> ./install.sh

Sur des customisations simples, celles-ci devraient avoir été récupérées par le processus de mise à jour.