Cliquez ici pour la version française
Version 1.6.1 (july 2018)
This document defines the technical framework of the Federation Education-Recherche. All those participating in this Federation must conform to the terms in this framework, which will insure the interoperability of the softwares components communicating within the Federation. This framework also defines the technical modalities used to translate their trust relationships technically from one system to another.
The recommendations and obligations stipulated in this document may be modified by the Federation administrators. Such modifications may be required by, for instance, security problems, new functional needs and/or the appearance of a new standard or product used by the Federation or the evolution of existing ones. Participants in the Federation will be notified of any modifications before they become effective, as early on as possible.
SAML 2.0 is the reference specification for any federation entity, the previous SAML 1.1 specification being used only for backward compatibility. When an entity supports both version, it must use SAML 2.0 by default.
Any entity registered in the federation must provide the following endpoints:
SAML 2.0 Web Browser SSO
profile, with HTTP POST
binding, in attribute push
SAML 2.0 Web Browser SSO
profile, with HTTP Redirect
Any entity registered in the federation may provide the following endpoints:
Shibboleth Authentication Request profile [ShibArch]
SAML 1.1 browser/POST profile, in attribute push mode [SAMLv1.1]
The profiles requiring direct SOAP
exchanges between the Federation's Shibboleth components (e.g., the Artifact profiles) will presumably not function in the Federation, because the Identity Providers are not necessarily configured for such exchanges. Thus, member institutions are strongly encouraged not to use profiles requiring back channel SOAP
Usage of the following software is recommended, as they benefit from documentation on this website, and from technical support by the federation operator:
Usage of the previous major version of those sofware (2.x) is technically possible, but not recommended, with a limited support from the federation operator, and no support from software editor, especially for any security issue. Oldest version (1.x) should not be used.
If accepted by the federation operator, other software MAY BE used in the Federation, provided they comply with the following criteria:
the software must implement the standards retained by the Federation (see above) and must be usable while respecting the other points defined in the technical framework (see below);
the software must not, in the opinion of the federation operator, generate excessive constraints for the technical service in terms of Federation's operation;
the software must not, in the opinion of the federation operator, generate excessive constraints in the configuration and administration of the software used by the other participants in the Federation;
all interoperability tests and conformance must be done under the only responsibility of the organization implementing such softwares.
No support nor documentation are provided for these other softwares. Such softwares may be later forbidden by the Federation if it prevents the technical framework from evolving (e.g., in the case of accepting a new standard or a new version of a supported software).
A list of the “declared” attributes of the Federation is published on this website. Recognized by all member institution Identity Providers, this attributes list is based on the SupAnn [SupAnn] standard. The resource administrators are asked to consult this list to verify whether or not the attributes required by their systems are on the list. If this is the case, resource administrators can refer to the list to indicate the attributes needed by their resources to their Identity Providers.
If the attributes needed by the resource are not on the list of “declared” attributes of the Federation, there are two possible scenarios:
The attributes are specific to the resource or to a limited subset of Federation participants. In this case, the resource administrator is free to ask for these attributes, with the accord of the concerned Identity Providers. It is the resource administrator's responsibility to document the naming protocols, the semantics and the nomenclatures associated to these attributes.
The attributes could be beneficial for other Federation members. In this case, the resource administrator is asked to contact the Federation's technical operators to propose that these attributes be included on the Federation's list of official attributes.
An Identity Provider can register with the Federation without being required to provide all the attributes listed above. However, if the Identity Provider release such official attributes, he must do it as mentioned and defined in the supAnn 2009 specifications.
The SAML assertions exchanged in the Federation are signed and possibly encrypted with X.509 certificates.
The certificate used by a SAML entity is published in the federation metadata. Trust in this certificates comes from the publication process, controled by the federation operator, acting as a trusted third-party for SAML exchanges in the federation. Therefore, there is no recognized certification authorities list, nor any revocation list. All certificate revocation and renewal operations are performed through the federation registry.
It is recommended to use long-lasting (between 5 and 10 years) self-signed certificates, as generated by many SAML software during installation, instead of certificates provided by certification authorities, because of their limited validity.
The integrity of metadata file is ensured by a digital signature, and the certificate used to check it is available on |this page. Its authenticity is ensured by HTTPS only access.
Please read the rules of the Fédération Éducation-Recherche certificates management.
If a resource already possesses an identifier, for example, because it belongs to another Federation, it can keep this identifier for its registration in the Federation Education-Recherche.
If this is not the case, Federation Identity Providers and Resource Providers MUST use a URL as an identifier (e.g., the notion of entityID in SAML2).
Examples of an entityID:
To improve the sustainability of the identifier, when possible, it is preferable to choose the name of the service rather than the name of physical host server as the domain name; also avoid mentioning the shibboleth software or a release number in that URL.
If several entities are hosted at the same domain (e.g., https://example.org/elarning et https://example.org/wiki), it is necessary to add a suffix to indicate the access path to the resources: https://example.org/elearning/sp/ and https://example.org/wiki/sp/.
The operator of the federation manages automatic filter attributes for identity providers. They are Shibboleth Identity Provider 2.3+ compliant.
There are several categories to allow fine-tuning filtering as specified in this page. (French only)
Nevertheless, it is required to promote the native and proper functioning of national resources by configuring the use of automatic national resources attributes filters.
It is therefore mandatory for Identity Providers to add an automated mechanism to download and process these filters.
In addition to the Éducation-Recherche federation, the operator provides other complementary federations.
The test federation, as its names implies, is dedicated to test services before production, and to conduct any kind of experimentation. Therefore, there is no preliminary condition to register an entity is this federation. However, its usage is supposed to be transient, and an entity must not be simultaneously be registered in this federation and in another production federation.
The eduGAIN federation is an inter-federation, aggregating multiple national federations as ours. The Éducation-Recherche federation applies an automatic registration policy, depending of the entity type:
Lastly, the local federations are private federations, whose visibility on the registry may be restricted, whose purpose is to provide services to a restricted audience.
In order to ensure reliable interactions between heterogeneous technical components, the SAML entities registered in the various forementionned federations must comply with several constraints, documented here. Those constraints are verified when declaring or modifying an entity on the federation registry, but may also be checked during periodical reviews.
The following rules apply to any kind of entity:
the entity must have a french name
the entity must have a french description
the entity must have a valid certificate for SAML exchanges, with an associated key at least 2048 bits long
the entity must have at least one personal technical contact
if the entity is SIRTFI compliant, it must have a dedicated security contact
if the entity is CoC compliant, it must have a confidentiality policy available online
the SAML endpoints must match the minimal requirements of section 1.0
the SAML endpoints must be secured by TLS, with a valid certificate, provided by a known certification authority
if provided, the logo must be a PNG
image, with a reasonable size (5120Kb maximum)
the entity must load the test federation metadata
The following additional rules apply to any service provider:
The following additional rules apply to any identity provider:
the authentication page must be secured by TLS, with a valid certificate, provided by a known certification authority
if provided, the logo dimensions must be exactly 16×16 pixels
The following additional rules apply to any kind of entity:
the entity must be attached to a member or partner organization
the entity must not be registered in the test federation
the entity must load the Éducation-Recherche federation metadata
The following additional rules apply to any kind of entity:
the entity must have an english name
the entity must have an english description
the entity must be registered in the Éducation-Recherche federation
the entity must load the eduGAIN federation metadata