Click here for the english version

Nouvelle version 1.6.3

Cadre technique de la Fédération Éducation-Recherche

Version 1.6.4 (mai 2021) (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.

1. Terminologie

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.

2. Normes utilisées dans la fédération

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 [ShibArch]
  • profil SAML 1.1 browser/POST en mode attribute push [SAMLv1.1]
Les profils nécessitant des échanges SOAP directs entre les briques techniques de la fédération (par exemple les profils Artifact) ne sont pas obligatoires et donc aucune garantie de leur bons fonctionnement ne peut être exigée. Il est donc fortement déconseillé d'utiliser ces profils.

3. Logiciels utilisables dans la fédération

L'utilisation des logiciels suivants est recommandée, car ils bénéficient de documentations sur ce site et du support technique par l'opérateur de la fédération:

  • Shibboleth Service Provider 3.x [ShibSPv3]: fournisseur de services ;
  • Shibboleth Identity Provider 3.x [ShibIdPv3]: fournisseur d'identités

L'utilisation des versions majeures précédentes de ces logiciels (2.x), bien que non recommandée, reste techniquement possible, mais 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 (1.x) ne doivent quand à elles plus êtres utilisées.

Sous réserve d'acceptation par l'opérateur de la fédération, d'autres logiciels de fédération pourront être utilisés, respectant notamment les critères suivants :

  • le logiciel doit implémenter les normes retenues dans la fédération (voir ci-dessus) et être utilisable en respectant les autres points définis dans le cadre technique (voir ci-dessous) ;
  • 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.

Aucun support ni documentation n'est fourni pour ces autres logiciels. Un tel logiciel peut être interdit à postériori dans la fédération s'il empêche des évolutions du cadre technique, par exemple l'acceptation d'une nouvelle norme ou d'une nouvelle version d'un logiciel supporté.

4. Liste d'attributs disponibles

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.

5. Gestion de la confiance au niveau technique

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

6. Identification des entités SAML

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:

Pour des raisons historiques, l'utilisation d'un URN (exemple : urn:mace:cru.fr:federation:univ-x.fr) comme identifiant est uniquement permise pour les organismes qui étaient préalablement membres de la fédération du CRU.

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 cet 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:

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

7. Automatisation de la diffusion des attributs utilisateurs

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.

Afin de simplifier la configuration de son fournisseur d'identités, un organisme peut bien sûr automatiser la diffusion des attributs utilisateurs pour les autres catégories de services.

8. Autres fédérations

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.

9. Recommandations et obligations

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.

9.1 Fédération de test

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

9.2 Fédération Éducation-Recherche

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

9.3 Fédération eduGAIN

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

10. Annexe : références