Version 0.3 (juin 2024)

Ce document définit les conditions générales d’usages auxquelles doivent se conformer les participants à la Fédération Éducation-Recherche. Ces règles sont des conventions destinées à garantir une relation de confiance entre les participants. En effet, si chaque organisme reste souverain dans les choix qu’il fait et les risques qu’il assume pour son propre système d’information, ceci n’est pas le cas pour un environnement mutualisé comme une fédération d’identité. Un autre document, le cadre technique du service, précise quand à d’autres règles, de nature technique, applicable à l'ensemble des fédérations opérées par le GIP Renater.

Les recommandations et obligations stipulées dans ce document pourront être régulièrement modifiées par l’opérateur du service. Ces modifications peuvent être motivées notamment par des problèmes de sécurité, de nouveaux besoins fonctionnels, l'apparition ou l'évolution d'une norme ou d'un produit. Elles seront préalablement, et le plus tôt possible, annoncées par courrier électronique aux participants du service.

Une entité SAML, comme n’importe quel autre composant informatique, peut être destiné à rendre un service effectif à son public cible, finalité qu'on qualifie généralement de production. Elle peut également être destinée à une autre finalité, et notamment celle de jouer le rôle de bac à sable à des fins de développement, de test, de validation, etc. sur une instance distincte de celle de production. Ces instances utilisant souvent des configurations moins durcies que les instances de pré-production, pour diverses raisons (finalisation non aboutie, contraintes supplémentaires, etc.), une pratique de sécurité commune consiste à isoler ces composants dans des environnements dédiés, et cloisonnés.

La même logique s'applique à la Fédération Éducation-Recherche, considéré comme un environnement dédié à la production, et les entités SAML qui ne sont pas dédiées à cet usage n'y ont donc pas leur place. Pour rappel, il existe deux autres fédérations de portée nationale:

• une fédération de qualification, pour les usages similaires à la production
• une fédération de test, pour tous les autres usages

La Fédération Éducation-Recherche est destinée à mettre à disposition des applications pour la communauté Enseignement/Recherche. Par conséquence, toute application qui y est enregistrée est réputée être accessible par l'ensemble des utilisateurs de l'ensemble de ces établissements.

Il est tout à fait envisageable néanmoins de restreindre cette accessibilité, à condition de respecter l'ensemble des points suivants:

• le contrôle d'accès doit être techniquement effectif
• l'utilisateur ne doit pas être pris en défaut
• le résultat doit être cohérent avec l'objectif de la fédération

Pour être effectif, le contrôle d'accès à une application doit être basée sur des mesures techniques adaptées, parmi lesquelles on peut citer:

• des restrictions au niveau réseau (filtrage IP)
• des restrictions au niveau SAML (filtrage des métadonnées chargées)
• des restrictions au niveau du serveur web (filtrage arbitraire au niveau du serveur web)
• des restrictions au niveau applicatif (filtrage arbitraire au niveau de l'application)

Pour rappel, la redirection d'un utilisateur vers un service de découverte, ou vers un IdP spécifique, opérée par un SP au moment de l'authentification d'un utilisateur, n'est pas une mesure de contrôle d'accès, et se contourne trivialement.

Un utilisateur ne doit pas se retrouver en face d'un message d'erreur incompréhensible ou ambigu pour lui, parce qu'il tente d'utiliser une application, pour quelque raison que ce soit, à laquelle il n'a cependant pas accès. Ce qui suppose que:

• la description du service dans les métadonnées de la fédération doit explicitement mentionner la limitation d'accès, idéalement de façon à ce qu'une simple lecture de cette description permette à l'utilisateur de savoir s'il est concerné ou non
• la page d'accueil du service, ou les conditions d'usage de celui-ci, si elles sont accessibles avant l'authentification, doivent être explicites également, avec les mêmes critères d'appréciation
• le service de découverte utilisé ne doit proposer que des fournisseurs d'accès correspondant à des utilisateurs susceptibles d'accéder au service: il n'est pas pertinent, par exemple, de passer par le service de découverte du GIP RENATER (https://discovery.renater.fr) pour un service destiné à une dizaine d'établissements, par exemple
• si un utilisateur, une fois authentifié, n'est cependant pas autorisé à accéder au service, le message d'erreur doit être explicite

Au delà d'un simple respect des utilisateurs, il s'agit également limiter les conséquences pour les autres participants, notamment les couts de support pour l'opérateur de la fédération, qui constitue souvent le seul interlocuteur identifié pour un utilisateur perdu…

Indépendamment des aspects évoqués plus haut, les restrictions d'accès mises en place doivent cohérentes avec l'objectif principal de la Fédération Education/Recherche: un service destiné aux utilisateurs d'un établissement unique, par exemple n'a rien à faire dans cette fédération, même si cette restriction est explicitement documentée partout où c'est nécessaire, et quelle que soit la façon dont elle est implémentée. Dans ce cas de figure, une relation bilatérale avec l'IdP en question permet d'arriver au même résultat, sans impacter l'environnement mutualisé constitué par une fédération nationale, qu'il s'agisse d'une pollution technique (augmentation inutile de la taille des métadonnées), ou d'une pollution organisationnelle (dilution du catalogue de service).

Les fédérations d'identité locales constituent également une alternative intéressante pour toutes les situations intermédiaires entre un service destiné à un établissement unique, et à l'ensemble des établissements de la communauté ESR.

La Fédération Éducation-Recherche est un environnement destiné à la communauté de l'enseignement supérieur et de la recherche. Par conséquence, toute les identités numériques qui y sont propagées sont censées correspondre à des utilisateurs identifiables, appartenant à cette communauté, et dont l'affiliation est explicite. Et tous les services qui y sont enregistrés doivent être rattachés explicitement à un participant identifiable.

Les identités propagées par un fournisseur d'identité doivent répondre aux exigences suivantes :

• elles doivent correspondre à des humains, identifiables en cas de réquisition judiciaire (pas de compte partagés) ;
• elles doivent correspondre à des personnes dépendant administrativement de l'établissement (pas de comptes invités, de personnels hébergés, de prestataires externes, …).

Les services doivent être rattachés à l'organisme qui en porte la responsabilité légale, et celui-ci doit être explicitement identifiable.

S'il est tout a fait possible d'enregistrer dans la fédération des briques techniques de type proxy HTTP, passerelle OIDC/SAML, fournisseur d'identité en cascade, ou tout autre dispositif intermédiaire entre un fournisseur d'identité et un service, cette architecture ne doit pas contrevenir aux règles précédentes, afin que les utilisateurs, d'une part, les administrateurs, d'autre part, puissent prendre des décisions en connaissance de cause. En conséquence:

• l'affiliation des utilisateurs doit être celle de leur établissement d'origine, même si leur identité est relayée par un établissement tiers
• le responsable légal d'un service doit être identifiable, même s'il est accédé au travers d'un dispositif porté par un organisme tiers
• la description du service doit correspondre à sa finalité, et pas à sa nature technique (ie, “passerelle OIDC” n'est pas une description valide)

Et bien sur, l'ensemble des organismes concernés doivent être adhérent au service de fédérations d'identité du GIP RENATER.