Cliquez ici pour la version française
RENATER publishes SAML metadata files associated to its federated identities infrastructure. These metadata files gather technical informations about identity providers (IdP) and service providers (SP) registered with RENATER through the federation registry.
If you run an SP or an IdP registered with RENATER, then informations about service must appear in these metadata files; you will also need to configure your software to load these metadata.
IMPORTANT : metadata evolution
From 2016-10-03 metadata files used so far evolve to increase their reliability. Before 2017-12-15 you must update your software configuration to load the new metadata files.
⇒ You must update your SP/IdP configuration : see §4.1
For production federations, different versions of the metadata files are proposed; each with different update frequency.
⇒ You have to choose a metadata version, depending on the type of SAML entity you manage and the federation it belongs to: see §4.2
Metadata are signed with a new hash algorithm (SHA256)
⇒ You need to download a new x.509 certificate : see §2.2
⇒ You need to configure you SP/IdP to use this new certificate for metadata signature validation : see §4.1
An history of past metadata versions is now available in a subdirectory called “history”.
This document provides all usefull informations to take this evolution into account.
RENATER manages different circles of trust and publishes metadata files each of these federations:
CRU accounts is an additional authentication service provided by RENATER. This identity provider is not part of the production federation, but you can download its SAML metadata.
Metadata files are updated automatically, based on data collected through our federation registry. This process validates the SAML metadata format, potential aggregation (eduGAIN case) and XML signing of metadata files.
Metadata updates occur at different frequencies, depending on the file version used, see the metadata versions description below.
Published SAML metadata have a validity period of 9 days. After the period your SP/IdP will probably not be able to use its local copy of the metadata file.
New metadata files get published in different versions, corresponding to a maturation process from preview to intermediate then main.
This metadata maturation process applies to all production federations (Education-Recherche federation, eduGain and local federations. However it does not apply to Test federation for which only the preview version is published
The current versions of new metadata files related to each federation are summarized in the table below :
For production federations, RENATER publishes other versions of metadata files, updated more frequently (see table below)
For metadata signature validation, you MUST download the new X509 certificate from the following url :
$ /usr/bin/curl -O https://metadata.federation.renater.fr/certs/renater-metadata-signing-cert-2016.pem
$ /usr/bin/openssl x509 -sha256 -noout -fingerprint -in renater-metadata-signing-cert-2016.pem
SAML metadata are build with technical informations provided by SP/IdP administrators via our federation registry. Registering an SP/IdP in a production federation and updating some technical informations require validation by federation contacts designated by your organization.
Access to the federation registry requires prior authentication. If you (don't yet) have your home identity provider registered in Fédération Education-Recherche, you need to create your CRU account beforehand.
To make your IdP/SP work with third-party SAML entities registered in a federation you need to configure your software to regularly load that federation SAML metadata file. We recommend that SP/IdPs reload metadata files every hour. This setup garanties that you will quickly benefit from any urgent metadata update by RENATER (even though the usual publication period of that file might by daily only).
Firewall/proxy setup: note that IP address of the metadata.federation.renater.fr server may change, without notice from RENATER. We therefore recommend that you define ACLs based on the server hostname, not based on its IP address.
Examples below describe how to load metadata for Federation Education-Recherche. You should adapt them for other federations.
For Shibboleth IdP 3.x :
For Shibboleth IdP 2.x :
<metadata:MetadataProvider id="RENATER" xsi:type="metadata:FileBackedHTTPMetadataProvider"
<!-- Trust engine used to evaluate the signature on loaded metadata. -->
<security:TrustEngine id="shibboleth.MetadataTrustEngine" xsi:type="security:StaticExplicitKeySignature">
<security:Credential id="TestCredentials" xsi:type="security:X509Filesystem">
For Shibboleth SP 2.x :
<MetadataProvider type="XML" uri="https://metadata.federation.renater.fr/renater/main/main-idps-renater-metadata.xml"
<MetadataFilter type="Signature" certificate="renater-metadata-signing-cert-2016.pem"/>
Depending on the type of SAML entity you manage and the federation it belongs to, you have to load different metadata files :
If you run an IdP:
| registered in || use this file
| Test federation || preview-sps-renater-test-metadata.xml
| Education-Recherche and eduGAIN federation (*) || main-sps-renater-metadata.xml AND main-sps-edugain-metadata.xml
(*) : by default IdPs registered in Education-Recherche federation also get registered in eduGAIN interfederation, unless they decide to get removed from eduGAIN (l'OPT-OUT principle). This behavior requires that reciprocally a French IdP loads SAML metadata with all SPs registered in eduGAIN. See this documentation (in French only) for IdPs participating in eduGAIN.
If you run a SP :
| registered in || use this file
| Test federation || preview-idps-renater-test-metadata.xml
| Education-Recherche federation || main-idps-renater-metadata.xml
| eduGAIN federation || main-idps-renater-metadata.xml AND main-idps-edugain-metadata.xml
If you run a DS (WAYF) :
| registered in || use this file
| Test federation || preview-all-renater-test-metadata.xml
| Education-Recherche federation || main-all-renater-metadata.xml
| eduGAIN federation || main-all-edugain+renater+sac-metadata.xml
If don't use a SAML implementation supported by RENATER (Shibboleth and SWITCH WAYF), we recommend beforehand that you check your SAML implementation is interoperable with our SAML2 metadata format through our Test federation. If your ensure interoperability problems, you should report them to that implementation's developers and possibly to RENATER.
If you use Shibboleth or SWITCH WAYF,
report us the problem you are facing. Shibboleth software keeps a local copy of metadata files that will be used, if you are unable to get a fresh version of the metadata files. That local version of metadata file may be used during 9 days.
The signature validation process of SAML metadata files published by RENATER uses the SHA-256 hash algorithm. This algorithm is handled by OpenSSL 0.9.8 (and later versions) and Java 4 (and later versions). If your SAML implementation is not able to validation the SAML metadata signature, you should check the version of the OpenSSL library you are using and possibly contact the support service of your SAML software. See the relevant documentation for Shibboleth: Shibboleth IdP signature interoperability issues.
We publish an history of past metadata versions for production federations. These historized versions may be found in each federation's history subdirectory.
Example for Education-Recherche federation :
If needed you can compare versions of metadata files or load an old version of a metadata file.