Click here for the english version
Ce document décrit l'ensemble des changements concernant l'infrastructure de gestion des fédérations du GIP RENATER, consécutifs à la mise en production de la version 3.0 de son interface web, le guichet de la fédération. Cette nouvelle version correspond à une refonte globale, de façon à moderniser et rationaliser l'infrastructure, tout en gardant fondamentalement les mêmes technologies, afin de faciliter la migration. Les principaux changements sont détaillés ci-dessous.
La charte graphique a été modernisée, et alignée sur les autres applications RENATER. L'utilisation du framework foundation constitue également un premier pas vers un affichage réactif.
La plupart des opérations (tri, filtrage, etc...) sont maintenant déléguées à la base de données, au lieu d'être effectuées par l'application, ce qui accélère leur traitement.
L'application est maintenant un frontal web exclusivement, et toutes les opérations annexes (envoi des notifications, génération des métadonnées, ...) sont maintenant effectuées de manière asynchrone par des processus externes, ce qui améliore les temps de réponse.
L'ancienne version du guichet permettait d'utiliser les métadonnées d'une entité SAML, pour remplir automatiquement toutes les informations techniques la concernant. Cette fonctionnalité souffrait de plusieurs limitations/défauts :
La nouvelle version propose la même fonctionnalité d'assistance à la saisie, mais à partir de fichiers de métadonnées transmis par le navigateur de l'utilisateur, ce qui élimine les problèmes d'accès réseau. De plus, il est maintenant interactif, permettant de vérifier le résultat avant soumission. Enfin, il est généralisé à tout type d'entité.
La validation des données a été largement améliorée, avec notamment l'ajout d'une première phase de contrôle au niveau du navigateur, permettant de guider l'utilisateur lors de la saisie. De plus, l'ensemble des erreurs est maintenant affiché en une seule fois lors de la soumission d'un formulaire, avec des messages qui ont évolué pour plus de clarté.
Le formulaire d'édition d'une entité SAML a été revu, les informations mieux réparties entre les différents onglets, et une aide contextuelle plus détaillée ajoutée à certains éléments pour préciser leur utilisation, comme par exemple les logos. Il a également été harmonisé entre les deux types d'entité : il est maintenant possible de déclarer des points d'accès de type Single Logout aussi bien pour un fournisseur d'identité que de service.
L'affichage de la liste des entités est maintenant paginable.
L'ancienne version du guichet utilisait le terme de contact technique pour désigner des personnes en charge de maintenir les informations sur l'application, et dont l'adresse constitue un identifiant pour gérer les droits d'accès sur l'application. Mais ces adresses étaient également publiées dans les métadonnées si une adresse supplémentaire, dite adresse technique générique, n'était pas fournie. Cette double fonction était à la fois source de confusion, et peu conforme aux exigences du RGPD, qui requiert une mention claire de l'utilisation des données personnelles.
La nouvelle version utilise maintenant une terminologie plus explicite, pour marquer la différence entre les deux fonctions:
Pour chaque entité SAML, il y a donc un ou deux responsables, un contact technique obligatoire, et un contact sécurité facultatif.
Pour toutes les entités existantes qui n'avaient aucun contact technique défini jusqu'ici, une recopie de la valeur de l'adresse du premier responsable a été faite au moment de la transition, et peut maintenant être corrigée si nécessaire.
Le modèle de données a été revu, pour permettre d'être plus flexible dans la définition de contraintes. Il n'est en effet pas pertinent d'imposer par exemple un nom et une description en anglais a une entité SAML dès sa déclaration, si celle-ci n'a pas vocation à être enregistrée dans la fédération eduGAIN, et donc exposée à une communauté non francophone. Certaines contraintes ne sont donc plus imposées dès la création d'une entité, mais uniquement au moment de son enregistrement dans une fédération spécifique.
Ces condititions d'enregistrement, entièrement configurables, reprennent pour l'essentiel des containtes qui existaient déjà, mais qui étaient codées en dur dans l'application, par exemple l'exigence d'un rattachement validé à un organisme pour être enregistré dans une fédération qualifiée jusque là de production, c'est-à-dire toutes celles de test. Nous préférons aujourd'hui le vocabulaire moins ambigu de fédération modérée, par analogie avec une liste de diffusion, pour parler d'une fédération associée à un processus de validation humaine (la modération) et automatique (le respect des conditions d'enregistrement).
Pour les fédérations nationales (Education/Recherche) et internationales (eduGAIN), ce nouveau modèle permet également d'implémenter des conditions d'enregistrement qui n'étaient jusqu'ici que mentionnées dans le cadre technique de la fédération, comme par exemple l'interdiction d'un enregistrement simultané dans la la fédération de test. Ces nouvelles contraintes s'inscrivent dans un effort global d'amélioration de la qualité globale des données de nos fédérations, comme présenté lors des JRES 2019.
Pour les fédérations locales, il constitue également un pas supplémentaire vers la mise en place de fédérations d'identité alternatives sur mesure, avec une exposition moindre et des règles plus adaptées.
La liste des attributs disponibles a été alignée sur la dernière révision de la recommandation SupAnn, SupAnn 2020, et ils sont regroupés en catégories (base, eduPerson, SCHAC, supAnn) pour plus de lisibilité.
Afin de limiter l'utilisation d'attributs inadaptés, chacun d'eux possède maintenant un statut, en fonction du contexte d'utilisation identifié dans ce document de référence:
Les attributs avec ce dernier statut, mais encore utilisés à l'heure actuelle, restent présents pour des raisons de compatibilité, sans être sélectionnables.
L'ancienne version du guichet mettait en oeuvre une politique d'enregistrement implicite dans la fédération eduGAIN: tout fournisseur d'identité enregistré dans la fédération Education/Recherche y était également enregistré automatiquement. Si cette pratique a sans doute contribué à augmenter la participation des établissements français à eduGAIN, elle n'est pas sans impact. En particulier, il est quelque peu difficile d'exiger des responsables de ces fournisseurs d'identité qu'ils se conforment à des exigences réglementaires (la constitution d'eduGAIN) ou techniques (le chargement des métadonnées d'eduGAIN), sans que ceci résulte d'un choix explicite de leur part. De plus, ceci est quelque peu en contradiction avec le discours de l'équipe fédération sur le fait de ne pas enregistrer systématiquement ses entités SAML dans toutes les fédérations disponibles, mais de le faire uniquement dans les fédérations pertinentes, en fonction du degré d'exposition souhaitable.
Cette politique n'existe plus, et il faut désormais demander explicitement l'enregistrement de toute entité SAML dans la fédération eduGAIN.
Les modération d'actions nécessitant une validation (rattachement à un organisme, enregistrement dans une fédération modérée, modification de données sensibles) se font désormais via un formulaire distinct du formulaire d'édition, pour plus de clarté, et l'ensemble des requêtes en attente pour une entité peuvent être validées ou refusées en une seule fois. De plus, une zone de commentaire permet d'expliciter au demandeur la raison d'un éventuel refus.
Les mails de notification sont désormais au double format HTML/texte.
Le code a été durci, et un effort particulier a été fait pour limiter les attaques de type XSS et CSRF.
Des contrôles supplémentaires ont été mis en place pour les comptes à privilèges, permettant de limiter les fournisseurs d'identité et les méthodes d'authentifications utilisables pour les administrateurs.
Les métadonnées ne changent ni de format, ni de contenu, ni de certificat de signature, à l'exception de l'ajout des points d'accès SAML de type SLO pour les IdPs, qui n'étaient jusqu'ici pas déclarables.
En revanche, l'URL de téléchargement des métadonnes évolue, pour rationaliser l'écosystème. Jusqu'ici, les métadonnées étaient téléchargées depuis un point d'accès dédié, tandis que les filtres d'attributs l'étaient depuis un autre. Dorénavant, toutes les resources téléchargeables liées à la fédération (aujourd'hui les métadonnées et les filtres d'attributs, demain potentiellement d'autres) seront publiées depuis un point d'accès unique, correspondant à l'arborescence suivante:
Si seules ces URLs canoniques sont maintenant mentionnées dans notre documentation, et nos exemples, les anciennes URLs de téléchargement des métadonnées seront maintenues, afin de garantir une compatibilité transparente: il n'est donc pas nécessaire de changer vos configurations.
Les filtres d'attributs générés par le guichet sont aujourd'hui obsolètes, dans la mesure où depuis la version 3.0 de l'IdP Shibboleth, datant de 2014, celui-ci est capable d'assurer la même fonctionnalité dynamiquement de son coté, comme expliqué dans notre documentation sur le filtrage automatique
En conséquence, les filtres d'attributs spécifiques à un SP unique on été supprimés, et les autres types de filtres d'attributs (par fédération, par catégorie de service, et par audience) ne sont maintenus temporairement que pour ceux qui sont encore utilisés par certains IdPs. Il seront définitivement supprimés dans une version ultérieure du guichet.
Comme mentionné ci-dessus, l'URL de téléchargement des filtres évolue : https://pub.federation.renater.fr/filtres
Les anciennces URLs de téléchargement des filtres conservés dans un soucis de compatibilité.
