SAML metadata generation is a sensitive process because these metadata are used in an heterogeneous environment and the federation operator cannot fully test the behavior of SAML entities regarding SAML metadata. This observation and our 10 years of experience with running a federation led us to a workflow to increase the level of assurance of our SAML metadata. This workflow relies on the participating institutions' participation. Our goal is to reduce the risks of disruptions of the service while preventing metadata files corruption.

Metadata files of production federations (all except the Test federation) get published in different versions, corresponding to a maturation process from preview to intermediate and main, see the schema below.

This process help make the production metadata more reliable: the less critical services will use a frozen of the metadata (names intermediate); le more critical services will use experienced metadata (main version) that have been used during half a day in their intermediate form. The preview metadata version is of interest if update frequency matters.

Versions available for each federation:

The below array shows caracteristics of each metadata files version and our recommandations regarding their usage. However each SP/IdP administrator may choose which metadata version best fits his service constraints.

Depending on which metadata file version you load, it will take more time before your SP/IdP takes other SAML entities updates into account. You should therefore consider this propagation delay while updating your SP/IdP informations via the federation registry, to find out when other SAML entities registered in the same federation might get your updated information.

As an example, after an update via the federation registry, new informations will get published:

• in the preview metadata
  • at most 30 minutes later,
• in the intermediate metadata
  • if you do the update via the registry before 1.30PM, at most 6h30 later,
  • if you do the update via the registry after 1.30PM, at most 18h30 later,
• in the main metadata
  • at most 1 day and 30min later.

You should also take into account the metadata reload frequency at each SP/IdP; RENATER recommends it to be hourly.
See this documentation (French only).

For eduGAIN metadata, you also need to consider the delay for metadata to be transmitted from one federation operator to another.
See the eduGAIN documentation (French only).