Remplacer un IdP Shibboleth par Entra ID : commencer par les journaux

Dans l'enseignement supérieur, l'authentification aux services académiques (plateformes de recherche, bibliothèques numériques, services de la fédération) passe souvent par un fournisseur d'identité Shibboleth, membre d'une fédération comme RENATER et de l'interfédération eduGAIN. Quand l'établissement a déjà Microsoft Entra ID pour Microsoft 365, la question arrive vite : peut-on tout faire reposer sur Entra ID et éteindre l'IdP ? Voici la démarche que j'ai suivie pour y répondre, sans casser l'accès des utilisateurs.

Commencer par les journaux, pas par la configuration

La tentation est de partir de la configuration de l'IdP : la liste des services déclarés, les filtres d'attributs. Mais la configuration dit ce qui est possible, pas ce qui est utilisé. Le journal d'audit de Shibboleth (idp-audit.log) enregistre chaque authentification réussie : le service demandeur, l'utilisateur, le format d'identifiant et les attributs transmis.

En analysant plusieurs mois de ce journal, on obtient en quelques heures :

la liste des services réellement utilisés, avec le nombre de connexions et d'utilisateurs distincts ;
pour chacun, les attributs effectivement transmis ;
le format de NameID attendu (transitoire ou persistant).

Le résultat est souvent surprenant : une poignée de services concentre l'essentiel du trafic, et beaucoup de services déclarés ne sont jamais sollicités. C'est cette mesure qui doit fixer l'ordre de la migration.

Recenser les attributs à reproduire

Les services académiques attendent des attributs du schéma eduPerson que Microsoft 365 n'utilise pas : eduPersonPrincipalName, eduPersonUniqueId, eduPersonScopedAffiliation, eduPersonAffiliation, parfois eduPersonTargetedID, en plus de mail, displayName, givenName et sn.

Côté Entra ID, chaque application d'entreprise SAML permet de personnaliser les revendications émises. Il faut donc décider d'où viendra chaque valeur : attributs existants de l'annuaire, attributs d'extension, ou transformations. L'affiliation (étudiant, personnel, enseignant) est souvent le point le plus délicat, car elle dépend de données qui vivent parfois dans le système d'information de scolarité ou de RH.

La question de la fédération

Un IdP Shibboleth consomme les métadonnées de toute la fédération : n'importe quel service membre peut lui demander une authentification. Microsoft Entra ID, lui, fonctionne service par service : chaque fournisseur de services SAML est déclaré comme application d'entreprise, et Entra ID n'est pas conçu pour charger un agrégat de métadonnées de fédération multilatérale.

Deux approches se dessinent alors :

Déclarer individuellement dans Entra ID les quelques services réellement utilisés, quand c'est accepté par la fédération et par le service ;
conserver un proxy SAML membre de la fédération, qui délègue l'authentification à Entra ID : l'utilisateur ne voit plus qu'une seule connexion, et la compatibilité fédérée est préservée.

Le bon choix dépend du nombre de services, des exigences de la fédération et de la capacité de l'équipe à maintenir un composant supplémentaire.

Piloter avant de basculer

Pour le pilote, je recommande de combiner deux types de services :

un service simple et peu risqué, qui n'attend que quelques attributs : il valide la chaîne technique de bout en bout ;
le service le plus utilisé d'après les journaux : il valide la compatibilité là où l'enjeu est réel.

Pour chaque service : déclarer l'application, émettre les revendications attendues, tester avec des comptes de chaque affiliation, puis comparer les attributs reçus avec ceux observés dans les journaux de l'ancien IdP.

Ce que je retiens

Les journaux décident : on ne migre que ce qui est utilisé, dans l'ordre de l'usage.
Les attributs eduPerson sont le vrai chantier, pas le protocole SAML lui-même.
La fédération multilatérale impose un choix d'architecture explicite : déclaration service par service ou proxy.
Un pilote à deux services, l'un simple et l'autre critique, sécurise toute la suite.