La migration d'un fournisseur de service (SP) peut intervenir à l'occasion d'un changement de serveur ou à l'occasion d'un changement de version du logiciel Shibboleth. Dans ce cas, le problème est lié au changement de certains éléments techniques, utilisés par les fournisseurs d'identité de la Fédération Éducation-Recherche. Le risque est l'interruption du service pendant le temps de propagation des nouvelles méta-données. Nous vous présentons ci-dessous une méthode permettant ne pas interrompre le service.

Il est important de déclarer auprès de la fédération les nouvelles coordonnées techniques de votre ressource, quelques jours avant la migration effective. En effet le délai de propagation de ces informations auprès des fournisseurs d'identité peut prendre plusieurs heures (entre 1h et 24h selon la configuration de chaque établissement).

Recommandations concernant les éléments techniques pouvant changer lors de la migration :

• Intitulé du service : la modification de ce champ n'a aucun impact sur les fournisseurs d'identité ;
• Liste des attributs requis : si votre ressource a besoin de nouveaux attributs, vous devez anticiper la mise à jour de cette information, car la diffusion de nouveaux attributs nécessite une intervention manuelle de la part de l'administrateur d'un fournisseur d'identité ;
• URL du service : pas d'impact direct sur les fournisseurs d'identité ;
• URL de vos méta-données : si vous utilisez un SP Shibboleth 2.x, vous devez déclarer l'URL d'accès aux méta-données de votre ressource ; ce qui vous évite de déclarer certaines informations manuellement ;
• EntityID : il s'agit de l'identifiant de votre ressource. Comme cet identifiant est utilisé comme clé par les fournisseurs d'identité (notamment pour la diffusion d'attribut), évitez de modifier votre entityID ;
• URL du service AssertionConsumerService : déclarer votre nouvelle URL quelques jours avant la migration effective. Mettez en place une redirection HTTP sur vos serveur pour l'AssertionConsumerService
  1. avant la migration : pour renvoyer les accès au nouveau point d'accès vers l'ancien,
  2. après la migration : pour renvoyer les accès à l'ancien point d'accès vers le nouveau
• Certificat X.509 : vous pouvez déclarer deux certificats pour une même ressource ; c'est adapté dans votre cas pour ne pas casser le service le temps de propagation des méta-données auprès des IdPs. Dans le formulaire de la fédération, déclarez l'ancien certificat dans le champ du même nom, si vous en changez.