La migration d'un fournisseur d'identité correspond au remplacement d'un fournisseur d'identité fonctionnel par un autre, avec généralement un changement de version majeur à la clé, par opposition à une simple montée de version in-situ. Cette documentation mentionne les différents point à prendre en compte pour minimiser les impacts, et propose plusieurs stratégies de transition, de complexité variable.
Les mêmes principes généraux s'appliquent à la migration d'un fournisseur de service, mais ce dernier cas de figure est généralement beaucoup plus simple à réaliser.
Il y a trois stratégies possibles:
Les développeurs de l'IdP Shibboleth préconisent fortement la première solution, dans leur guide de migration:
Finally, you must install the new version on top of your previous installation. This is not only safe but essential to properly maintain a working system.
Dans les faits, ce n'est pas strictement obligatoire, mais le processus de configuration est beaucoup plus conservateur dans ce cas, et s'efforce de minimiser les changements, donc les impacts potentiels. Si vous n'êtes pas à l'aise avec la configuration d'un IdP, et l'utilisation de la documentation officielle, cela est généralement plus simple à gérer. Inversement, cette méthode contribue à conserver des mécanismes historiques, et des algorithmes cryptographiques obsolètes, afin de maintenir une compatibilité ascendante, sans aucun moyen d'évaluer l’intérêt effectif d'une telle mesure. Bien entendu, il est plus prudent de partir d'un clone de l'instance actuelle.
la seconde stratégie est plus longue à mettre en œuvre, mais évite d'accumuler des scories au fur et à mesure des migrations. Elle nécessite néanmoins une bonne pratique du sujet, et l'utilisation de la documentation officielle pour comprendre les changements.
La dernière stratégie cumule les désavantages des deux autres, et aboutit en général à des situations dysfonctionnelles. Typiquement, elle va activer la mise en place du registre d'attribut (alors que ce n'est pas le cas lors d'une mise à jour), avec une configuration du résolveur d'attribut historique faisant double emploi, ce qui se manifeste par un double encodage des attributs, et des valeurs dupliquées.
La liste des éléments dont la modification à l'issue du changement peuvent avoir un impact sont les suivants:
Aucun de ces impacts n'est réellement bloquant, mais en fonction de votre contexte, ils peuvent être plus ou moins importants. Si vous ne comprennez pas de quoi il s'agit, vous n'êtes généralement pas concernés.
L'identifiant SAML (propriété idp.entityID dans le fichier idp.properties) est ce qui permet aux différents fournisseurs de service interagissant avec un fournisseur d'identité de l'identifier. Si cet identifiant change, ceci a les conséquences suivantes:
Maintenir le même identifiant en changeant d'IdP est tout a fait possible, mais l'impossibilité de déclarer simultanément plusieurs entités SAML avec le même identifiant sur le guichet de la fédération, ainsi que l'immutabilité de cet identifiant, nécessite le recours à des stratégies plus complexe que d'utiliser un identifiant distinct.
Pour rappel, un identifiant SAML utilise la syntaxe d'une URL, mais uniquement à des fins d'unicité, avec la sémantique d'une chaine de caractère, et ce n'est pas une URL d'accès au service. Autrement dit, il est tout a fait possible de garder un éventuel identifiant historique https://idp.domaine.tld/idp/shibboleth, même après avoir redéployé le nouvel IdP sur une machine nommée idp2.domaine.tld, du moment que les adresses d'accès aux différents points d'accès SAML dans les métadonnées pointent bien vers les nouvelles URLs.
En général, les utilisateurs ne connaissent du fournisseur d'identité que le nom qui s'affiche au niveau du service de découverte. Si celui-ci change, en fonction de la communication qui leur a été faite, ils peuvent être capables ou non d'utiliser le nouveau service.
Il est trivial de faire en sorte que le nom soit le même à l'issue de la migration, mais l'impossibilité d'enregistrer simultanément dans la FER deux entités avec le même nom peut éventuellement obliger à les renommer après la bascule en cas de double déclaration.
Le sel cryptographique des identifiants persistants (propriété idp.persistentId.salt dans le fichier saml-nameid.properties) est ce qui sert à assurer la non-reversabilité d'un secret. Si celui-ci change:
Plusieurs stratégies de transition peuvent être envisagées, qui s'articulent autour des deux possibilités suivantes, de complexité croissante:
Etant donné la complexité du sujet, il est souvent préférable d'opter pour une stratégie simple et maitrisée (la première en général), que pour une stratégie plus élaborée, même si ses bénéfices annoncés semblent plus intéressant, mais dont l'échec aura en général des conséquences plus fortes.
Cette stratégie est la plus simple, mais implique un changement d'identifiant SAML du fournisseur d'identité, avec les conséquences exposées plus haut. Les autres paramètres peuvent être préservés.
Elle consiste à déclarer un nouveau fournisseur d'identité, avec un nouvel identifiant, comme n'importe quel autre entité SAML, en passant par la fédération de test dans un premier temps, dans la Fédération Education/Recherche, dans un second temps. Les deux fournisseurs d'identités coexistent alors dans la même fédération, et n'importe quel utilisateur peut alors choisir explicitement d'utiliser l'un ou l'autre
La bascule définitive peut alors se faire de deux façons:
Dans un cas comme dans l'autre, il faut ensuite supprimer l'enregistrement de l'ancien fournisseur d'identité dans la Fédération Education/Recherche, puis le supprimer complètement du guichet et le décommissionner à l'issue d'une période suffisante pour valider la migration.
Cette stratégie est plus complexe, et demande de comprendre comment s'opèrent les échanges SAML pour être maitrisée. Elle peut en revanche être totalement transparente, avec une durée de bascule (ou de retour en arrière) beaucoup plus courte, puisqu'elle ne repose plus sur la propagation de changements via les métadonnées.
En effet, les échanges SAML reposent sur des redirections HTTP effectuées par le navigateur de l'utilisateur, et jamais sur des échanges directs entre serveurs. Autrement dit, il suffit de jouer sur la résolution DNS d'un ou plusieurs postes de travail (via le fichier /etc/hosts sur une machine Unix, via vue DNS spécifique, etc.) pour que l'utilisateur de celui-ci interagisse avec le nouveau fournisseur d'identité, plutôt qu'avec l'ancien, à condition que la configuration de ces deux fournisseurs d'identité soient strictement identiques (même identifiant, même adresses de points d'accès SAML, etc.), à l'adresse IP près.
Cette stratégie ne demande pas de déclarer la nouvelle instance sur le guichet, ni de l'enregistrer dans une quelconque fédération d'identité: du point de vue du reste du monde, il n'y a qu'une seule entité SAML.
La bascule définitive consiste à modifier l'enregistrement DNS correspondant au fournisseur d'identité pour le faire pointer sur l'adresse de la nouvelle instance.
