Migration IdP 3.4 vers IdP 4

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

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 de l'IdP - pour un IdP 3.4 installé comme décrit dans notre tutoriel.

Bien qu'il soit possible de migrer un IdP 3.4 en IdP 4, il peut être intéressant de planifier une mise à jour de l'IdP 4 en prenant en compte les modifications structurelles apportées à la configuration de l'IdP. Notamment sur l'encodage et la résolution d'attributs.

Les règles de formatage nécessaire pour les attributs supAnn sont disponibles dans la documentation sur la génération d'attribut.

Tout comme pour l'IdP 3.4, il existe un plugin disponible pour qu'un IdP 4 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.

Si vous utilisez un serveur CAS, vous avez néanmoins d'autres possibilités :

Outre les upgrades techniques (Spring 5…), les principales nouveautés fonctionnelles de l'IdP 4 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
  • A partir de l'IdP 4.1, une refonte majeure de la configuration mais « rétro-compatible »
    • Suppression du répertoire et des fichiers « System »
    • Auto-détection de plus de composants depuis les jars
    • Beaucoup d’éléments de configuration en XML migrés dans des fichiers de propriétés (Configuration de l'IdP4)
      • authn/authn.properties remplace authn/XXX-authn-config.xml
      • admin/admin.properties remplace admin/general-admin.xml
      • conf/c14n/subject-c14n.properties remplace c14n/XXX-c14n-config.xml
    • Suppression du fichier session-manager.xml (configuration au besoin dans global.xml)
    • Certains fichiers de configuration xml devenus optionnels ne sont plus installés par défaut (ils sont installés avec les modules)
  • A partir de l'IdP 4.1, une nouvelle architecture dédiée aux modules et aux plugins pour gérer et faciliter tous les futurs ajouts de fonctionnalités et les extensions (Utilisation des modules (pour l'IdP Shibboleth 4.1 et supérieur))
  • A partir de l'IdP 4.2, changement du thème de l'interface utilisateur par défaut (vues, css…)
    • Fichiers main.css, consent.css, logout.css remplacé par placeholder.css
    • Nouvelle propriété idp.css pour définir le fichier de css customisé

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.

Cette étape est nécessaire si votre IdP ne présente pas d'utilisation de syntaxe dépréciée. C'est le cas si vous avez suivi le guide d'installation publié à partir de fin septembre 2020.

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.

Fichier Type {namespace}Nom Remplacement
attribute resolver Element {urn:mace:shibboleth:2.0:resolver}Dependency {urn:mace:shibboleth:2.0:resolver}InputDataConnector
{urn:mace:shibboleth:2.0:resolver}InputAttributeDefinition
attribute resolver Attribut sourceAttributeID InputAttributeDefinition
InputDataConnector
attribute resolver Type {urn:mace:shibboleth:2.0:attribute:encoder}SAML1String {urn:mace:shibboleth:2.0:resolver}SAML1String
attribute resolver Type {urn:mace:shibboleth:2.0:attribute:encoder}SAML2String {urn:mace:shibboleth:2.0:resolver}SAML2String
attribute resolver Type {urn:mace:shibboleth:2.0:resolver:ad}Simple {urn:mace:shibboleth:2.0:resolver}Simple
attribute resolver Type {urn:mace:shibboleth:2.0:resolver:ad}Script {urn:mace:shibboleth:2.0:resolver}ScriptedAttribute
attribute resolver Type {urn:mace:shibboleth:2.0:attribute:encoder}SAML1ScopedString {urn:mace:shibboleth:2.0:resolver}SAML1ScopedString
attribute resolver Type {urn:mace:shibboleth:2.0:attribute:encoder}SAML2ScopedString {urn:mace:shibboleth:2.0:resolver}SAML2ScopedString
attribute resolver Type {urn:mace:shibboleth:2.0:resolver:ad}Scoped {urn:mace:shibboleth:2.0:resolver}Scoped
attribute resolver Type {urn:mace:shibboleth:2.0:attribute:encoder}SAML1XMLObject {urn:mace:shibboleth:2.0:resolver}SAML1XMLObject
attribute resolver Type {urn:mace:shibboleth:2.0:attribute:encoder}SAML2XMLObject {urn:mace:shibboleth:2.0:resolver}SAML2XMLObject
attribute resolver Type {urn:mace:shibboleth:2.0:resolver:ad}SAML2NameID {urn:mace:shibboleth:2.0:resolver}SAML2NameID
attribute resolver Type {urn:mace:shibboleth:2.0:resolver:dc}Static {urn:mace:shibboleth:2.0:resolver}Static
attribute resolver Type {urn:mace:shibboleth:2.0:resolver:dc}LDAPDirectory {urn:mace:shibboleth:2.0:resolver}LDAPDirectory
attribute resolver Type {urn:mace:shibboleth:2.0:resolver:dc}StoredId {urn:mace:shibboleth:2.0:resolver}StoredId

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.

Modification des balises ''<Dependency>''

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
Cette page n'a pas pour objectif de décrire l'installation de Java 11 ou Tomcat 9.
La mise en place avec Tomcat 9 est similaire à la mise en place avec Tomcat 8.

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

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

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

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

Sur des customisations simples, celles-ci devraient avoir été récupérées par le processus de mise à jour.
Réaliser des test et “faire le ménage” de tout ce qui n'est pas ou plus utile.

Un exemple de montée de version vers l'IdP 4.1 est reporté sur https://shibboleth.atlassian.net/wiki/spaces/KB/pages/1469908146/Example+4.1+Upgrade.

  • federation/documentation/fiches-techniques/idp/migration-idp4.txt
  • Dernière modification : 2023/04/20 11:15
  • de ludovic.auxepaules@renater.fr