Cliquez ici pour la version française

Federation Éducation-Recherche technical framework

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.

1. Terminology

  • Entity : it is a technical entity such as an Identity Provider or a Service Provider that provides or processes SAML assertions;
  • Federation Management interface : it is the Web interface run by RENATER and allowing organizations registering and managing their technical entities.

1. Standards used in the Federation

The following standard will be implemented by all the software supported by the Federation:

  • SAML 1.1 [SAMLv1.1]. Not mandatory and still supported for backward compatibility. This specification may onlyu be used with the Shibboleth profiles, Authentication Request and browser/POST [ShibArch] with attribute push enabled.

The following standard MUST BE implemented in the Federation:

  • SAML 2.0 [SAMLv2] restricted to:
    • Web Browser SSO Profile using the binding HTTP POST
    • Web browser Redirect SSO profile

  • All the profiles that require 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 exchanges.
  • Other SAML2 profiles may be used but with no interoperability guaranty.

2. Software that may be used in the Federation

The following software is recommended and the only supported within the Federation Education-Recherche.

  1. Shibboleth 2.0 [Shibv2.0] ;
  2. Shibboleth 1.3.x [Shibv1.3] is no more supported and thus MUST NOT be used anymore.

This website offers documentation for the supported software and the technical support by the Federation's technical service.

If accepted by the Federation's technical service, other software MAY BE used in the Federation. These software must comply to 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 technical service, generate excessive constraints for the technical service in terms of Federation's operation;
  • the software must not, in the opinion of the technical service, 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).

3. List of the Federation's official attributes

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.

4. Trust Fabric Certificates

The SAML assertions exchanged in the Federation must be signed and possibly encrypted with X.509 certificates. They are never seen by the end user's browser.

The certificate used by Identity Providers or Resource Providers must be published in the metadata. This certificate can be either self-signed or signed by some certification authority. The trust in this certificate is due solely to the fact that it is published in the metadata and that this publication has been controlled by the Federation administrators. Thus, the trust in the certificate is not predicated on the fact that the certificate has been published by a given certification authority. Consequently, there is no list of Federation-recognized certification authorities. The revocation or renewal of certificates is done via the Federation's management web interface.

  • The Federation's metadata file is digitally signed to ensure its integrity. The certificate used to check that integrity is available on this page SAML metadata published by RENATER;
  • The metadata file must be downloaded at its HTTPS URL;
  • The updating of this metadata file is processed and controlled by the Federation administrators.

Please read and comply to the rules of the Fédération Éducation-Recherche certificates management.

5. Naming Protocol for Identity Providers and Resource Providers

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 resources or several Identity Providers 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 the name of the domain to indicate the access path to the resources: https://example.org/elearning/sp/ and https://example.org/wiki/sp/.

6. Using Automatic Attributes Filters

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.

7. Miscellany

  • It is mandatory that resources use HTTPS instead of HTTP for their AssertionConsumerService URL.
  • It is mandatory for Identity Providers to use an authentication system whose authentication's page can be uniquely accessed in HTTPS, using an SSL browser-facing certificate natively recognized by the user's browsers (often commercial Certification Authority).

SSL browser-facing certificates are not part of the federation trust fabric. They are not used in the entity's or federation's metadata.

Appendix: References

[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

[Shibv2.0]: Shibboleth 2.x http://shibboleth.net/

[SupAnn]: SupAnn, http://www.cru.fr/documentation/supann/index