Un événement récurrent dans notre communauté est la fusion entre plusieurs établissements, et le souhait pour le nouvel établissement de se doter d'une nouvelle identité spécifique, dont l'un des éléments constitutifs est le nom de domaine.
En conséquence, une double question revient régulièrement au support technique du GIP RENATER :
En tant qu'opérateur de fédération, nous ne pouvons pas faire grand chose, hormis expliciter les différents cas d'usage d'un nom de domaine dans une fédération d'identité, et notamment la différence entre un domaine de messagerie, et un domaine de qualification des attributs.
En tant que fournisseur de services, néanmoins, nous pouvons vous aider à quantifier l'impact du changement, mais uniquement sur nos propres services. Pour les autres services inscrits dans la Fédération Education-Recherche, il faudra examiner la fiche de chacun d'entre eux sur le guichet de la fédération (pour la version facile) ou directement dans les métadonnées de celle-ci (pour la version geek) pour tenter d'obtenir l'information.
Le domaine de messagerie est le nom de domaine utilisé pour la partie droite d'une adresse email: prenom.nom@domaine.tld.
Ce domaine est lié au nom de domaine d'un établissement, et au système DNS, parce qu'il doit être résolvable pour que les mails soient correctement routés vers les passerelles de messageries.
Voici une liste non exhaustive de services du GIP RENATER, avec pour chacun d'eux les conséquences d'un changement d'adresse email:
Cette liste met en évidence un problème : l'adresse email reste un identifiant utilisateur courant dans beaucoup d'applications, pour des raisons historiques, même si ce n'est pas conforme à nos préconisations actuelles sur le sujet. Ainsi toute modification de l'attribut mail d'un utilisateur propagé par son IdP (ce qui n'est pas exactement la même chose que son adresse email officielle) va entrainer un changement dans l'identification d'un utilisateur pour ces services.
Deux critères permettent également de relativiser l'impact réel du changement:
Attention, il n'est question ici que des impacts techniques concernant l'utilisation du service : pour PASS par exemple, qui utilise l'attribut ePPN pour identifier les utilisateurs, un changement d'adresse email est sans effet “technique”. Il existe cependant des obligations contractuelles de maintien à jour des informations de contacts dans la plupart des documents engageant les établissement utilisateur des services RENATER, comme par exemple la charte de la Fédération, qui ne sont pas précisées ici.
Une fois l'impact mesuré, les différentes stratégies suivantes peuvent être envisagées
Cette stratégie est envisageable dans certains cas, typiquement s'il y a peu d'utilisateurs et qu'ils sont autonomes techniquement.
Cette stratégie dépend essentiellement des possibilités techniques et du bon vouloir des administrateurs en charge du service. Pour plus d'efficacité, il est recommandé d'ouvrir un ticket par service depuis le portail d'assistance, puisque chaque service est en général géré par une équipe différente de notre coté, et que ceci permet de paralléliser le travail, et de faciliter la compréhension du problème pour les gestionnaires de service, plutôt qu'un ticket unique qui passe de main en main avec un historique difficile à déchiffrer.
Pour le seul service opéré directement par l'équipe fédération d'identité, le guichet de la fédération, nous nous occupons en général d'aligner les contacts fédération de l'établissement cible sur les ceux définis dans PASS, puis nous rattachons l'ensemble des entités à ce nouvel établissement. Ces contacts sont ensuite autonome pour mettre à jour ces entités.
Cette stratégie est plus technique, et mérite quelques explications. Ce n'est pas parce que l'adresse officielle d'un utilisateur passe de prenom.nom@domaine.tld à prenom.nom@autre-domaine.tld qu'il est obligatoire pour autant de propager immédiatement cette nouvelle valeur via l'IdP de cet établissement. Continuer à propager l'ancienne valeur prenom.nom@domaine.tld, surtout si celle-ci continue de toute façon à fonctionner techniquement, n'entrainera aucun dysfonctionnement : le routage SMTP n'a en effet pas grand chose à voir avec le fonctionnement d'une fédération d'identité. Et il est même possible de propager sélectivement l'ancienne valeur à certaines applications uniquement, en jouant sur la configuration de l'IdP (plus précisément, le sous-système attribute resolver) de l'IdP, à condition de maitriser le sujet. Et cette stratégie de compatibilité n'est pas forcément définitive, elle peut très bien être mise en place le temps d'effectuer une transition sereinement, application par application.
Le domaine de qualification des attributs constitue la partie droite des attributs dits qualifiés, dont par exemple l'attribut eduPersonPrincipalName (ePPN): prenom.nom@domaine.tld.
Même si ma syntaxe utilisée est indiscernable à première vue d'une adresse électronique, ce domaine n'est en fait lié au nom de domaine d'un établissement que par convention, pour assurer son unicité, sans aucune adhérence technique avec le système DNS.
En conséquence, il n'est absolument pas nécessaire de modifier ce domaine, et donc la valeur de l'attribut ePPN, qui est censé être un identifiant pérenne, suite à un changement du nom de domaine officiel d'un établissement. Il est beaucoup plus simple d'utiliser un domaine de qualification correspondant à un ancien domaine DNS (tant qu'il n'est pas ré-attribué à un autre établissement), voire même plusieurs suite à une fusion entre établissements différents, au sein d'un même IdP, plutôt que de vouloir réattribuer une nouvelle identité homogène à tous les utilisateurs, ce qui n'a aucun intérêt en soi.
Si néanmoins vous tenez à aligner le domaine de qualification sur le nom de domaine officiel du nouvel établissement, la même démarche que pour un changement du domaine de messagerie s'applique: étude d'impact dans un premier temps, choix d'une stratégie pour gérer les changements dans un second temps.
Il existe bien un attribut eduPersonPrincipalNamePrior (ePPNP), destiné à gérer automatiquement un changement de valeur de cet identifiant, et donc minimiser son impact, il faut relativiser son intérêt au regard de son utilisation réelle. Or, à l'heure actuelle, cet attribut n'est demandé en tout et pour tout que par 6 fournisseurs de services enregistré dans la Fédération Education/Recherche (dont le SP de test, qui ne le demande que pour l'afficher), autant dire qu'il est sous-utilisé.
