Version 1.6.8 (june 2024)

This document defines the technical framework of the Fédération Éducation-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.

Terminology

• Entity : a technical entity such as an Identity Provider or a Service Provider that provides or processes SAML assertions;
• Federation registry : web management interface, run by federation operator, allowing organizations to register and manage their entities.

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 mode [SAMLv2]
• SAML 2.0 Web Browser SSO profile, with HTTP Redirect binding [SAMLv2]

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]

Usage of the following software is recommended, as they benefit from documentation and support, from the federation operator and from the editor:

• Shibboleth Service Provider 3.x [ShibSPv3]
• Shibboleth Identity Provider 5.x [ShibIdPv5]

Usage of the previous major version of those sofware is technically possible, with a limited support from the federation operator, and no support from software editor, especially for any security issue. Oldest version should not be used.

Any other SAML implementation compatible with identity federation requirements may be used, with following conditions:

• it must implement the standards retained by the federation and defined in this technical framework;
• it must not generate excessive constraints for the federation operator (according to the federation operator)
• it must not generate excessive constraints for the other participating members (according to the federation operator)
• all interoperability tests and conformance must be done under the only responsibility of the organization implementing such softwares.

Warning, SAML support only implies support for the authentication protocol, not for the auto-configuration mechanism allowing to automatically establish trust relationship with other identity federation participating members. A software requiring to manually establish bilateral relationship, such as Keycloack for example, is not usable without a gateway such as SATOSA.

No support nor documentation are provided for these other softwares. It is nevertheless possible to get minimal community-based support from other users of the ESR community, though federation-utilisateurs discussion list.

A list of the “declared” attributes of the Federation is available from federation registry. 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 trust in those certificates, that is their validity according to the point of view of a SAML entity, comes from their declaration in the federation metadata, published and signed by the federation operator. Contrarily to the TLS trust model, based on trusted third-parties known as certification authorities, these are not involded here, and are completly ignored. There is no explicit revocation procedure, a renewal operation through the federation registry is enough to make the previous one invalid.

As there is no added-values to certificates provided by certification authorities, which are usually plagued by limited validity, it is preferable to use long-lasting (between 5 and 10 years) self-signed certificates, as generated by many SAML software during installation. And if some SAML implementations don't check expiration limites, it is still mandatory to use currently valid certificates for interoperability purpose.

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 Féderation Éducation-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:

• https://idp.univ-test.fr/idp
• https://wiki.univ-test.fr/sp

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

There are several entity 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.

Identity providers use one or several attribute qualification domains, named scope in the SAML2 specification, so as to ensure unicity of some values, typically user dentifiers, in a distributed environment.

As for entity identifers, those domains should not use arbitrary values, but values whose unicity can be established. As a consequence, those domains must be:

• public
• under the control of the organization which this identiy provider is attached

In addition to the Féderation Éducation-Recherche , 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 Féderation Éducation-Recherche applies an automatic registration policy, depending of the entity type:

• the identity providers are registered by default (opt-out policy)
• the service providers are not registered by default (opt-in policy)

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 ou GIF image, with a reasonable size (5120Kb maximum)
• the entity must load the test federation metadata

The following additional rules apply to any service provider:

• all the required user attributes must be justified by a short purpose description (authentication, display, etc.)

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 Féderation Éducation-Recherche 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 Féderation Éducation-Recherche
• the entity must load the eduGAIN federation metadata

• [SAMLv1.1]: Security Assertion Markup Language (SAML) v1.1, http://www.oasis-open.org/specs/index.php#samlv1.1
• [SAMLv2]: Security Assertion Markup Language (SAML) v2.0, http://www.oasis-open.org/specs/index.php#samlv2.0
• [ShibArch]: Understanding Shibboleth https://wiki.shibboleth.net/confluence/display/SHIB2/UnderstandingShibboleth
• [ShibSPv3]: SP Shibboleth v3.x
• [ShibIdPv5]: IdP Shibboleth v5.x
• [SupAnn]: SupAnn, Annuaires pour l'Enseignement Supérieur (Supann)