Migration d'un fournisseur d'identité

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.

Déploiement de la nouvelle instance

Les développeurs de l'IdP Shibboleth préconisent de partir d'une installation existante, plutôt que d'une installation nouvelle, 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. Typiquement, l'installation d'une version 4.x met en place le nouveau mécanisme de registre d'attributs, tandis qu'une mise à jour depuis une version 3.x conserve l'ancien système. 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.

De surcroit, cette méthode conservera également la configuration d'origine, et notamment les éléments spécifiques au fournisseur d'identité (identifiant SAML, salt, etc.) détaillés au paragraphe suivant, et facilitera la diminution de l'impact.

Inversement, cette methode 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.

Afin de ne pas modifier l'instance actuelle, il est bien évidemment recommandé de partir d'un clone de celle-ci, disposant de la même configuration, sur une autre machine.

Impact des modifications

La liste des éléments dont la modification à l'issue du changement peuvent avoir un impact sont les suivants:

  • l'identifiant SAML (entityID)
  • le nom du fournisseur d'identité
  • le sel des identifiants persistants

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.

Identifiant SAML (entityID)

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:

  • toutes les relations bilatérales (hors fédération, donc) deviennent caduque
  • les éventuelles configurations spécifiques d'une fournisseur de service lié ce fournisseur d'identité deviennent caduque
  • les identifiants utilisateurs persistant basés sur cet identifiant (ePTID, notamment) deviennent caduque

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.

Nom du fournisseur d'identité

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.

Sel des identifiants persistant

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:

  • les identifiants persistants générés à la volée (computed persistentId) deviennent caduque
  • les identifiants persistants stockés (stored persistentId) existants ne sont pas affectés

Stratégie de transition

Plusieurs stratégies de transition peuvent être envisagées, qui s'articulent autour des deux possibilités suivantes, de complexité croissante:

  • cohabitation des deux instances
  • masquage de l'ancienne instance par la nouvelle

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.

Cohabitation

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:

  • en demandant explicitement aux utilisateurs d'utiliser le nouveau fournisseur d'identité
  • en échangeant les noms de deux fournisseurs d'identité sur le guichet de la fédération, ce qui revient à faire utiliser le nouveau fournisseur d'identité aux utilisateurs à leur insu (il faut néanmoins compter sur le délai de propagation des métadonnées)

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.

Masquage

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.