Version 1.6.8 (juin 2024) (Historique des modifications)

Ce document définit le cadre technique de la Fédération Éducation-Recherche auquel doivent se conformer les participants à la Fédération Éducation-Recherche. Ce cadre permet d'assurer l'interopérabilité entre les briques techniques communicant dans la fédération. Il définit également les modalités techniques mises en œuvre pour traduire techniquement leurs relations de confiance.

Les recommandations et obligations stipulées dans ce document pourront être régulièrement modifiées par l'opérateur de la fédération. 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 utilisé dans la fédération. Elles seront préalablement, et le plus tôt possible, annoncées par courrier électronique aux participants de la fédération.

entité : fait référence à une entité produisant ou consommant des assertions SAML, à savoir un fournisseur d'identités ou une ressource (associé à un fournisseur de services).

guichet de la fédération : interface web de gestion, mis en œuvre par l’opérateur de la fédération, permettant aux organismes d'enregistrer des entités auprès de la fédération, et d'effectuer la mise à jour des informations techniques de ces entités.

La norme SAML 2.0 est la norme de référence pour toute entité de la fédération, la version précédente SAML 1.1 n’étant utilisée qu’à des fins de rétro-compatibilité. Lorsque l’entité supporte les deux versions, elle doit utiliser SAML 2.0 par défaut.

Toute entité enregistrée dans la fédération doit fournir au minimum les points d’accès SAML 2.0 suivant :

• profil Web Browser SSO en utilisant le binding HTTP POST et en mode attribute push [SAMLv2]
• profil Web Browser SSO en utilisant le binding HTTP Redirect [SAMLv2]

Toute entité enregistrée dans la fédération peut fournir les points d’accès suivants :

• profil Shibboleth Authentication Request
• profil SAML 1.1 browser/POST en mode attribute push [SAMLv1.1]

L'utilisation des logiciels suivants est recommandée, car ils bénéficient d'une documentation et d'un support technique à la fois par l'éditeur et par l'opérateur de fédération:

• Shibboleth Service Provider 3.x [ShibSPv3]
• Shibboleth Identity Provider 5.x [ShibIdPv5]

L'utilisation de la précédente version majeure de ces logiciels reste acceptée, avec un support limité de la part de l'opérateur de la fédération, et aucun de la part de l'éditeur, en particulier pour tout problème de sécurité. Les versions antérieures ne doivent quand à elles plus êtres utilisées.

N'importe quelle autre implémentation SAML compatible avec les besoins d'une fédération d'identité est néanmoins utilisable, aux conditions suivantes:

• le logiciel doit implémenter les normes retenues dans la fédération et définies dans ce cadre technique ;
• il ne doit pas induire des contraintes excessives pour l'opérateur de la fédération (à son appréciation) ;
• il ne doit pas induire des contraintes excessives dans la configuration et l'administration des logiciels utilisés par les autres participants de la fédération (à l'appréciation de l'opérateur de la fédération) ;
• Les tests d'interopérabilité avec les logiciels de référence sont à la charge exclusive de l'établissement qui introduit ces autres implémentations.

Attention, le support SAML implique uniquement le support du protocole d'authentification, pas du mécanisme d'auto-configuration permettant d'établir automatiquement des relations de confiance avec les autres participants au sein d'une fédération d'identité. Un logiciel reposant sur l'établissement manuel de relations bilatérales, comme Keycloack par exemple, n'est pas utilisable sans l'utilisation d'une passerelle type SATOSA.

Aucun support ni documentation spécifique n'est fourni pour ces autres logiciels par l'opérateur de fédération. Il est néanmoins possible de s'adresser aux autres utilisateurs de la communauté ESR, via la liste de discussion federation-utilisateurs, pour obtenir un support communautaire.

La liste des attributs disponibles est accessible sur le guichet de la fédération. Ces attributs proviennent de plusieurs normes, certaines à portée nationale comme SupAnn, certaines de portée internationale comme SCHAC ou eduPerson.

L'administrateur d'un fournisseur d'identité n'a aucune obligation d'implémenter ces attributs, mais s'il le fait, il doit respecter la sémantique associée, telle que définie dans la documentation associée.

L'administrateur d'un fournisseur de service est invité à consulter cette liste, et les définitions associées, pour identifier les attributs nécessaires au fonctionnement de son application. Il faut néanmoins garder à l'esprit les points suivants:

• il n'y aucune garantie, ni même aucune visibilité, sur la capacité des différents fournisseurs d'identité, à implémenter ou à partager avec un tiers ces différents attributs
• la réglementation sur les informations à caractère personnel, et notamment le RGPD, imposent de réduire l'utilisation de ces informations aux seules réellement nécessaire (principe du privacy by design)
• certains de ces attributs sont destinés avant tout à un usage local au sein de leur SI d'origine, et ne sont pas adaptés à l'usage au sein d'une fédération d'identité, par exemple parce qu'ils n'apportent aucune garantie d'unicité, et ne sont mentionnés que pour des raisons historiques

Dans le cadre d'une fédération d'identité, il est donc conseillé de se restreindre à des ensembles normalisés d'attributs, comme par exemple celui préconisé par la spécification R&S, plutôt de piocher dans cette liste au cas par cas. Il importe également d'être cohérent avec le périmètre de la fédération considérée: il est inutile d'attendre de fournisseurs d'identité étrangers, par exemple, qu'ils implémentent un attribut supAnn, et une application inscrite dans eduGAIN doit donc éviter de dépendre de l'un d'entre eux.

Certains besoins récurrent, et notamment le choix d'un identifiant utilisateur, sont par ailleurs détaillés dans notre documentation.

Les assertions SAML échangées dans la fédération sont signées et potentiellement chiffrées avec des certificats X.509.

La confiance dans ces certificats, c'est-à-dire le fait qu'ils sont considérés comme valides par une entité SAML, vient du fait qu'ils sont déclarés dans les méta-données de la fédération, qui sont publiées et signées par l'opérateur de la fédération. Contrairement au modèle de confiance utilisé pour TLS, basé sur des tiers de confiance nommées autorités de certification, celles-ci ne jouent strictement aucun rôle, et sont complétement ignorées. Et il n'y a pas de procédure de révocation explicite, le simple renouvellement d'un certificat, via le guichet de la fédération, revient à révoquer l'ancien.

Puisqu'il n'y a aucune plus-value à utiliser des certificats émis par des autorités de certification, mais qu'au contraire ceux-ci sont pénalisés par des durées de validité courtes, il est préférable d'utiliser des certificats auto-signés à longue durée de validité (entre 5 et 10 ans), comme en génèrent beaucoup de logiciels SAML lors de l’installation. En effet, si certaines implémentations SAML ignorent cette durée de validité, il reste obligatoire de veiller à utiliser des certificats en cours de validité à des fins d'interopérabilité.

L'intégrité du fichier des méta-données est assurée par une signature électronique, et le certificat permettant de vérifier celle-ci est disponible sur cette page. Son authenticité est assurée par un accès exclusif sur une URL HTTPS.

Merci de lire ces obligations et recommandations quant à la gestion des certificats dans le cadre de la fédération d'identités

Les entités SAML possèdent toutes un identifiant, désigné par le terme d'entityID dans la spécification SAML 2.

Cet identifiant doit être une URL HTTP ou HTTPS, par exemple:

• https://identites.univ-test.fr
• http://wiki.univ-test.fr/sp

Il ne s'agit pas d'un point d'accès, aucun navigateur ne tentera de résoudre cette URL et d'y accéder. En revanche, il s'agit d'un identifiant, il doit donc être pérenne et unique, ce qui entraine plusieurs conséquences.

Tout d'abord, s'il n'est pas interdit d'utiliser un nom de serveur physique, de logiciel ou de version, l'évolution d'un de ces éléments ne doit pas entrainer une modification de l'identifiant, peu importe qu'il ne corresponde plus à la réalité technique sous-jacente.

Ensuite, il ne suffit pas d'utiliser une URL arbitraire, mais une URL dont il est possible de garantir que personne d'autre en dehors de l'organisme qui met en oeuvre l'entité ne sera en mesure de l'utiliser, volontairement ou non, pour identifier une autre entité. Par conséquence, le nom de domaine utilisé doit être:

• public
• sous le contrôle de l'organisme auquel cette entité est rattachée

Typiquement, les URLs suivantes, bien que syntaxiquement valides, ne sont pas utilisables comme identifiant, parce qu'elles ne se basent pas sur des domaines publics:

• https://localhost/idp
• https://service.local
• http://CiscoISE/e7764019-13b7-4f54-8a25-ce35772731b4

Et une URL https://service.renater.fr n'est un identifiant valide que pour une entité SAML mise en oeuvre par le GIP RENATER.

Les fournisseurs d'identité utilisent un ou plusieurs domaines de qualification des attributs, désigné par le terme de scope dans la spécification SAML 2, afin d'assurer l'unicité de certaines valeurs, typiquement les identifiants, au sein d'un environnement distribué.

Comme pour les identifiants d'entités, il ne doit pas s'agir de domaines arbitraires, mais des domaines dont il est possible de garantir que personne d'autre en dehors de l'organisme qui met en oeuvre l'entité ne sera en mesure de les utiliser, volontairement ou non, pour identifier une autre entité. Par conséquence, les domaines utilisés doivent être:

• public
• sous le contrôle de l'organisme auquel ce fournisseur d'identité est rattachée

L'opérateur de la fédération propose une classification des fournisseurs de services par portée (locale, nationale, …) et par type (documentation en ligne, accès wifi, …). Cette classification permet aux administrateurs des fournisseurs d'identités de définir des politiques de diffusion des attributs utilisateurs par catégories de services, en se basant sur la présence de valeurs standardisées, nommées Entity categories, dans les méta-données SAML de la fédération.

Dans le but de garantir le bon fonctionnement des services nationaux, tout fournisseur d'identités doit automatiser la diffusion des attributs utilisateurs requis par ces services (catégorie https://federation.renater.fr/scope/national) par une règle autorisant tous les attributs demandés.

En plus de la Fédération Éducation-Recherche, l’opérateur propose plusieurs autres fédérations complémentaires.

Afin d’effectuer des tests préalables à la mise en production, et d’une façon plus générale n’importe quelle expérimentation, il existe une fédération de test, dont l’accès n’est soumis à aucune condition préalable. L’inscription dans cette fédération est supposée être transitoire, et il n’est pas souhaitable qu’une entité soit inscrite simultanément dans cette fédération et dans une autre fédération de production.

La fédération eduGAIN est une inter-federation, regroupant plusieurs fédération nationales comme la notre. La Fédération Éducation Recherche applique une politique d’inscription de ses propres entités différentes en fonction de leur type :

• les fournisseurs d’identités sont inscrit par défaut, sauf choix explicite (politique de type opt-out)
• les fournisseurs de service ne sont pas inscrites par défaut, sauf choix explicite (politique de type opt-in)

Enfin, les fédérations locales sont des fédérations privées, dont la visibilité peut d’ailleurs être restreinte, destinées à offrir des services à une population plus restreinte que l’ensemble de la communauté éducation-recherche.

Afin de fiabiliser les interactions entre des briques techniques hétérogènes, les entités inscrites dans les différentes fédération mentionnées précédemment doivent respecter un certain nombre de contraintes, détaillées ici. Ces contraintes sont notamment vérifiées lors de la déclaration ou de la modification des informations liées à cette entité via le guichet de la fédération, mais peuvent également l’être lors de revues périodiques.

Les obligations suivantes s’appliquent à tout type d’entité :

• l'entité doit avoir un intitulé en français
• l'entité doit avoir une description en français
• l'entité doit avoir un certificat valide pour la couche SAML, avec une clé associée d’une longueur d’au moins 2048 bits
• l'entité doit avoir au moins un contact technique individuel
• si l'entité est conforme SIRTFI, elle doit avoir un contact dédié
• si l'entité est conforme CoC, elle doit avoir une politique de confidentialité accessible en ligne
• les points d’accès SAML définis doivent correspondre au minimum à ceux cités au paragraphe 1.0
• les points d’accès SAML définis doivent être sécurisés par l’utilisation de TLS, avec un certificat valide, délivré par une autorité de certification reconnue
• s'il est défini, le logo doit être au format PNG ou GIF, et de taille raisonnable (maximum 5120Ko)
• l'entité doit charger les métadonnées de la fédération de test

Les obligations supplémentaires suivantes s’appliquent à tout fournisseur de services :

• tous les attributs utilisateurs requis doivent être justifiés par une description succincte de l’usage qui en est fait (authentification, affichage, etc.)

Les obligations supplémentaires suivantes s’appliquent à tout fournisseur d’identités :

• la page d’authentification doit être sécurisée par l'utilisation de TLS, avec un certificat valide, délivré par une autorité de certification reconnue
• les dimensions d'un éventuel logo sont fixées à 16×16 pixels

Les obligations supplémentaires suivantes s’appliquent à tout type d’entité:

• l'entité doit être rattachée à un organisme membre ou partenaire
• l'entité ne doit pas être inscrite dans la fédération de test, et ne pas charger les métadonnées correspondantes
• l'entité doit charger les métadonnées de la Fédération Éducation-Recherche

Les obligations supplémentaires suivantes s’appliquent à tout type d’entité :

• l'entité doit avoir un intitulé en anglais
• l'entité doit avoir une description en anglais
• l'entité doit être inscrite dans la Fédération Éducation-Recherche
• l'entité doit charger les métadonnées de la fédération eduGAIN

• [SAMLv1.1]: Security Assertion Markup Language (SAML) v1.1
• [SAMLv2]: Security Assertion Markup Language (SAML) v2.0
• [ShibSPv3]: SP Shibboleth v3.x
• [ShibIdPv5]: IdP Shibboleth v5.x
• [SupAnn]: Annuaires pour l'Enseignement Supérieur (Supann)