Click here for the English version

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

Version 1.5 (20 juillet 2015) (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).

interface de gestion de la fédération : interface web opéré par RENATER 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.

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

La norme suivante peut être implémentée par des logiciels supportés dans la fédération, elle n'est plus norme de référence mais permet la rétro-compatibilité avec des logiciels anciennement installés :

  • SAML 1.1 [SAMLv1.1] avec les profils Shibboleth Authentication Request et browser/POST [ShibArch] en mode attribute push.

Toute nouvelle entité enregistrée dans la fédération devra au minimum déclarer des points d'accès SAML2.

La norme suivante doit être utilisée dans la fédération, c'est la norme de référence pour toute nouvelle entité enr dans la fédération :

  • SAML 2.0 [SAMLv2] avec le profil Web Browser SSO Profile en utilisant le binding HTTP POST et en mode attribute push.
  • SAML 2.0 [SAMLv2] avec le profil Web Browser Redirect SSO en utilisant le SAML2/Redirect/SSO

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.

2. 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 :

  1. Shibboleth 2.x [Shibv2.x] : fournisseur d'identités et fournisseur de services ;

Shibboleth 1.3.x [Shibv1.3] 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é.

3. 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.

4. 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 le logiciel de fédération d'un fournisseur d'identités ou d'une ressource doit être publié dans les méta-données de la fédération. Ce certificat peut-être auto-signé. La confiance dans ce certificat vient du fait qu'il est publié dans les méta-données et que cette publication est contrôlée par les opérateurs de la fédération :

  • ce certificat est cantonné à la couche SAML ;
  • beaucoup de logiciels SAML génèrent un tel certificat à longue durée de vie lors de son installation ;
  • des certificats émis par des autorités de certification peuvent être utilisés mais leur utilisation dans ce cadre est déconseillée.

La confiance dans ce certificat n'est donc pas lié à la signature par une autorité de certification. La fédération ne définit donc pas de liste d'autorités de certification reconnues. La révocation et le renouvèlement des certificats sont réalisés en mettant directement à jour les certificats via l'interface de gestion de la fédération.

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. La mise à jour des méta données est contrôlée par les opérateurs de la fédération.

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

5. 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/.

6. Automatisation de la diffusion des attributs utilisateurs

L'opérateur de la fédération propose une catégorisation des fournisseurs de services via des "entity categories" dans les méta-données SAML de la fédération. Ces “entity categories” permettent aux administrateurs des fournisseurs d'identités d'automatiser la diffusion des attributs utilisateurs aux fournisseurs de services.

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 les services nationaux au moyen des “entity categories” (voir cette documentation) 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 fournisseurs de services.

7. Divers

Il est recommandé aux ressources d'utiliser HTTPS au lieu de HTTP pour leur URL d'AssertionConsumerService. En effet, si HTTPS n'est pas utilisé, les utilisateurs verront un avertissement de leur navigateur quand ils reviennent de leur fournisseur d'identités vers la ressource. Cet avertissement leur indique qu'ils quittent une connexion sécurisée (car ils étaient en HTTPS sur le serveur du fournisseur d'identités) pour continuer sur une connexion non sécurisée (HTTP au niveau de la ressource). Cela leur donnerra l'impression (à tort) que la ressource elle-même n'est pas sécurisée.

Il est obligatoire pour les fournisseurs d'identités de s'appuyer sur un système d'authentification dont la page d'authentification est accessible uniquement en HTTPS, en utilisant un certificat serveur reconnu dans les navigateurs des utilisateurs (certificat d'autorité de certification).

Annexe : références