Click here for the english version

Méta-données SAML publiées par RENATER

RENATER publie des fichiers de méta-données SAML dans le cadre de son infrastructure de fédération d'identité. Ces fichiers de méta-données recensent les informations techniques sur les fournisseurs d'identité (IdP) et les fournisseurs de service (SP) renseignées auprès de RENATER au travers du guichet de la fédération.

Ces méta-données sont indispensable au fonctionnement d'une fédération d'identité, puisque les entités SAML doivent se connaitre mutuellement avant d'échanger le moindre message. L'authentification réciproque, par exemple, nécessite que chacun connaisse le certificat de signature de l'autre. En conséquence, pour pouvoir communiquer avec une autre entité enregistrée dans une fédération d'identité, une entité doit:

  • être enregistrée dans cette fédération d'identité, de façon à être présent dans les méta-données chargées par les autres
  • charger les méta-données de cette même fédération d'identité, de façon à connaitre les autres

L'enregistrement dans une fédération, via le guichet, ne constitue que la première partie de cette relation de confiance symétrique, et doit être complétée par une modification de la configuration.

1. Fédérations et méta-données

RENATER gère plusieurs cercles de confiance et publie un ou plusieurs fichiers de méta-données pour chacune de ces fédérations :

  • la Fédération Éducation-Recherche (plus d'info) : l'environnement de production pour la communauté éducation-recherche française ;
  • l'inter-fédération eduGAIN (plus d'info) : l'environnement de production pour la communauté éducation-recherche internationale. Les données publiées proviennent de GEANT, opérateur de eduGAIN ;
  • les fédérations locales (plus d'info) : des environnements de production pour des groupes d'établissements éducation-recherche français. L'URL des méta-données des fédérations locales n'est pas publique ;
  • la fédération de test (plus d'info) : l'environnement de test pour les organismes éducation-recherche.

Le service des comptes CRU est un service d'authentification complémentaire proposé par RENATER. Ce fournisseur d'identité n'est inscrit dans aucune fédération, mais vous pouvez télécharger ses méta-données individuellement.

2. Enregistrement dans une fédération

Les méta-données d'une fédération sont construites à partir des informations techniques fournies par les administrateurs des IdP/SP via le guichet de la fédération. L'enregistrement d'un SP/IdP dans une fédération de production ainsi que la modification de certaines informations techniques sont soumis à validation par les contacts fédération désignés par l'organisme (membre ou partenaire) dont vous dépendez.

L'accès au guichet de la fédération requiert une authentification. Si vous n'avez pas (encore) un fournisseur d'identité enregistré dans la Fédération Éducation-Recherche, vous devez au préalable créer votre compte CRU.

3. Publication des méta-données

Les fichiers de méta-données font l'objet d'un processus de mise à jour automatique, à partir des données saisies dans le guichet de la fédération. Ce processus prend en charge la validation du format des méta-données, l'agrégation éventuelle (cas de eduGAIN) et la signature XML des fichiers de méta-données.

Les mises à jour sont publiées à des fréquences différentes selon la version du fichier utilisée, voir la description des versions de méta-données ci-après.

Les méta-données SAML publiées ont une durée de validité de 9 jours. Après cette échéance votre IdP/SP ne sera vraisemblablement plus capable d'utiliser une copie locale d'un fichier de méta-données.

3.1 Versions des fichiers

Pour chaque fédération, nous publions plusieurs versions des méta-données, en fonction de deux critères différents, de façon à permettre plus de souplesse à chaque administrateur:

  • le niveau de maturité
  • le type d'entité

Le détail exact de ces différentes versions, avec les URLs associées, est précisé sur cette page dédiée.

3.1.1 Niveau de maturité

En temporisant la publication des modifications, avec des délais variables, il est possible de pouvoir intercepter une éventuelle erreur avant qu'elle ne se propage. A condition qu'elle soit détectée, cependant… Les versions les plus matures évoluent moins vite, ce qui signifie que les changements mettront plus de temps pour y apparaitre, mais sont en contrepartie moins susceptibles de contenir des erreur.

Pour chaque fédération (hormis la fédération de test et les fédérations locales), il existe donc 3 niveaux de maturité différents, correspondant à des délais de publications des modifications croissant:

  • preview: au maximum 30 minutes après la modification sur le guichet
  • intermediate: au maximum 6 heures après la modification sur le guichet
  • main: au maximum 12 heures après la modification sur le guichet
Ces délais ne correspondent qu'à la publication des changements dans les métadonnées. Pour que ces changements soient pris en comptes, il faut que ces métadonnées soit également rechargés par les autres entités de la fédération, ce qui correspond à un délai supplémentaire dépendant de la configuration de chacune d'entre elles.

3.1.1 Type d'entité

Dans une fédération d'identité, un SP communique exclusivement avec d'autres IdPs, jamais avec un autre SP (et réciproquement). En conséquence, il est inutile pour lui de connaitre les autres SPs membres de sa fédération, et donc de charger la partie des méta-données correspondant à ceux-ci. Même s'il est possible de mettre en place un filtre lors du chargement en mémoire, il est beaucoup plus de simple de télécharger uniquement une version pré-filtrée du fichier de méta-données de la fédération qui ne contient que le type d'entité souhaité.

Pour chaque fédération (hormis la fédération de test et les fédérations locales), et chaque niveau de stabilité, il existe donc trois version des métadonnées:

  • la version all contient toutes les entités de la fédération
  • la version sps contient uniquement les SPs
  • la version idps contient uniquement les IdPs

3.2 Signature des fichiers

Pour pouvoir vérifier la signature des fichiers de métadonnées, vous devez télécharger le certificat X.509 associé depuis l'adresse suivante : https://pub.federation.renater.fr/metadata/certs/renater-metadata-signing-cert-2016.pem

$ /usr/bin/curl -O https://pub.federation.renater.fr/metadata/certs/renater-metadata-signing-cert-2016.pem 
$ /usr/bin/openssl x509 -sha256 -noout -fingerprint -in renater-metadata-signing-cert-2016.pem
SHA256 Fingerprint=6B:D3:5F:7A:B1:64:EC:79:03:0D:36:97:BA:40:BD:23:5D:AA:DA:C0:43:47:C6:E5:3E:B7:72:A7:74:2C:16:5F

4. Chargement des méta-données

Pour que votre entité SAML accepte de dialoguer avec d'autres entités SAML de la même fédération, vous devez la configurer pour charger régulièrement le fichier de méta-données de la fédération. Nous vous recommandons de planifier cette synchronisation toutes les heures. Cette configuration vous garantit une prise en compte rapide en cas de modifications urgentes par RENATER (même si la fréquence de publication habituelle des méta-données n'est que quotidienne).

Votre IdP/SP est protégé par un firewall ou un proxy qui bloque les flux sortants: nous attirons votre attention sur le fait que l'adresse IP du serveur pub.federation.renater.fr peut changer, sans notification. Nous vous recommandons de mettre en place des règles de contrôle d'accès basées sur le nom de domaine, et pas sur l'adresse IP du serveur.

4.1 Exemples de configuration pour le logiciel Shibboleth

Les exemples ci-dessous gèrent le chargement des méta-données de la Fédération Éducation-Recherche. Vous devrez les adapter pour les autres fédérations (eduGAIN, test, fédérations locales).

Pour le logiciel Shibboleth IdP 3.x/4.x :

metadata-providers.xml
<MetadataProvider id="RenaterMetadata"
                      xsi:type="FileBackedHTTPMetadataProvider"
                      backingFile="%{idp.home}/metadata/main-sps-renater-metadata.xml"
                      metadataURL="https://pub.federation.renater.fr/metadata/renater/main/main-sps-renater-metadata.xml"> 
 
  <MetadataFilter xsi:type="SignatureValidation"
            requireSignedRoot="true"
            certificateFile="%{idp.home}/credentials/renater-metadata-signing-cert-2016.pem">
  </MetadataFilter>        
</MetadataProvider>

Pour le logiciel Shibboleth SP 3.x :

shibboleth2.xml
<MetadataProvider type="XML" url="https://pub.federation.renater.fr/metadata/renater/main/main-idps-renater-metadata.xml"
              backingFilePath="main-idps-renater-metadata.xml" reloadInterval="3600">
   <MetadataFilter type="Signature" certificate="renater-metadata-signing-cert-2016.pem"/>
</MetadataProvider>

4.2 Quel(s) fichier(s) de méta-données charger ?

Selon le type d'entité SAML que vous gérez et les fédérations dans laquelle elle est enregistrée, vous devez charger des fichiers de méta-données différents. Nous vous suggérons les fichiers suivants, mais vous pouvez également opter pour d'autres versions, en fonction du compromis rapidité/stabilité souhaité:

Dans le cas d'un IdP

inscrit dans utilisez le fichier
Fédération de Test preview-sps-renater-test-metadata.xml
Fédération Éducation-Recherche main-sps-renater-metadata.xml
eduGAIN main-sps-edugain-metadata.xml

Dans le cas d'un SP

inscrit dans utilisez le fichier
Fédération de Test preview-idps-renater-test-metadata.xml
Fédération Éducation-Recherche main-idps-renater-metadata.xml
eduGAIN main-idps-edugain-metadata.xml

Dans le cas d'un service de découverte

Le SP auquel est associé de service est inscrit dans utilisez le fichier
Fédération de Test preview-all-renater-test-metadata.xml
Fédération Éducation-Recherche main-all-renater-metadata.xml
eduGAIN main-all-edugain+renater+sac-metadata.xml

4.3 Mon SP/IdP ne parvient pas à charger les méta-données SAML

Si vous n'utilisez pas les implémentations de référence de RENATER (Shibboleth et SWITCH WAYF), nous vous recommandons de vérifier l'interopérabilité de votre implémentation SAML avec notre format de méta-données SAML2 via la fédération de test dans un premier temps. Si le problème persiste, tournez-vous vers les développeur du logiciel ou éventuellement vers RENATER.

Si vous utilisez Shibboleth ou SWITCH WAYF, signalez-nous le problème rencontré. Le logiciel Shibboleth gère une copie locale des fichiers de méta-données qui sera utilisée, faute de pouvoir en charger une version à jour ; cette version locale du fichier de méta-données est exploitable pendant 9 jours.

La vérification de la signature des méta-données SAML publiées par RENATER utilise l'algorithme de hashage SHA-256. Cet algorithme est géré par OpenSSL 0.9.8 (et versions plus récentes) et Java 4 (et versions plus récentes). Si votre implémentation SAML n'est pas capable de vérifier la signature des méta-données SAML, vérifiez la version de la bibliothèque OpenSSL et éventuellement contactez le support du logiciel SAML concerné. Voir la documentation Shibboleth IdP signature interoperability issues du consortium Shibboleth.