Click here for the English version

Nouvelle version 1.6

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

Version 1.6 (juin 2018) (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 la maîtrise d'ouvrage 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, d'effectuer mettre des mises à jour des informations techniques sur 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, ce sont les logiciels références de la fédération :

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

Shibboleth 1.3.x [Shibv1] n'étant plus maintenu par les auteurs du logiciel, cette version n'est également plus supportée par les administrateurs de la fédération. Les participants ne doivent plus utiliser cette version du logiciel Shibboleth dans le cadre de la fédération.

Ces logiciels supportés bénéficient de documentations sur ce site et d'un support par l'opérateur de la fédération.

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 officiels de la fédération

Une liste d'attributs officiels de la fédération est publiée sur cette page. Cette liste d'attributs, reconnue par l'ensemble des organismes membres fournisseurs d'identités, s'appuie sur la norme SupAnn [SupAnn]. Les administrateurs de ressources sont invités à consulter cette liste pour vérifier si les attributs requis par son système y sont listés. Si c'est le cas un administrateur de ressource peut y faire référence pour indiquer aux fournisseurs d'identités les attributs dont sa ressource a besoin.

Si les attributs dont la ressource a besoin ne sont pas présents dans la liste d'attributs officiels de la fédération, il y a deux possibilités :

  1. soit ces attributs sont spécifiques à cette ressource ou à un sous-ensemble limité de participants de la fédération. Dans ce cas l'administrateur de la ressource est libre de demander ces attributs, en accord avec les fournisseurs d'identités concernés ; charge à lui de documenter le nommage, la sémantique et les nomenclatures associées de ces attributs.
  2. soit ces attributs peuvent avoir un intérêt plus général pour d'autres membres de la fédération. Dans ce cas l'administrateur de la ressource est invité à prendre contact avec les opérateurs de la fédération pour lui proposer l'inclusion de ces attributs dans la liste d'attributs officiels de la fédération.

Un fournisseur d'identités peut être inscrit dans la fédération sans implémenter l'ensemble des attributs définis. Cependant si un attribut officiel est implémenté par un fournisseur d'identités, il doit l'être en se conformant au nommage, à la nomenclature et à la sémantique tels que défini dans les recommandations supAnn 2009.

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.

Le certificat utilisé par une entité SAML est publié dans les méta-données de la fédération. La confiance dans ce certificat vient du fait que cette publication est contrôlée par l’opérateur, qui joue de facto le rôle de tiers de confiance pour les échanges SAML au sein de cette fédération. Il n’y a donc pas de liste d'autorités de certification reconnues, ni de liste de révocation. Toutes les opérations de déclaration et de renouvellement des certificats sont réalisées en mettant à jour les informations sur cette entité via le guichet de la fédération.

Il est déconseillé d'utiliser des certificats émis par des autorités de certification à cause de leur durée de vie limitée, mais d'utiliser plutôt des certificats auto-signés à longue durée de vie1), comme en génèrent beaucoup de logiciels SAML lors de l’installation.

L'authentification et l'intégrité du fichier des méta-données sont assurées par une signature électronique et 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. Nommage des fournisseurs d'identités et des ressources

Du fait de son appartenance à une autre fédération, si un fournisseur d'identités ou une ressource possède déjà un identifiant, elle peut conserver cet identifiant pour son enregistrement dans la fédération Éducation-Recherche.

Sinon les fournisseurs d'identités et les ressources de la fédération doivent utiliser une URL comme identifiant (notion de entityID dans SAML2).

Exemples d'entityID :

L'utilisation d'un entityID sous forme d'un URN (exemple : urn:mace:cru.fr:federation:univ-x.fr) est uniquement permise pour les organismes qui étaient préalablement membres de la fédération du CRU.

Pour améliorer la pérennité de l'identifiant, il faut si possible choisir comme nom de domaine le nom du service plutôt que le nom du serveur physique l'hébergeant ou le nom du logiciel utilisé ; évitez de mentionnez le logiciel Shibboleth dans l'URL ou un numéro de version de logiciel.

Si plusieurs ressources ou plusieurs fournisseurs d'identités sont hébergés sur le même domaine (par exemple https://example.org/cours-en-ligne et https://example.org/wiki), il faut suffixer au nom du domaine le chemin d'accès à la ressource : https://example.org/cours-ligne/sp/ et https://example.org/wiki/sp/.

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, ou à défaut utiliser les filtres automatiques d'attributs proposés par RENATER (voir cette documentation).

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 Education-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 Education 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é Education-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 sont obligatoires à 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é 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
  • 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

Annexe : références

1) entre 5 et 10 ans