FCA – Pratique recommandée pour les exploitants de la Fédération : Inscription des métadonnées

Le modèle qui a servi de gabarit au présent document est exploité en vertu de la licence CC BY 3.0 de Creative Commons. Il peut être librement partagé, réutilisé ou modifié pourvu que les sources soient mentionnées. Ce document s’inspire des travaux réalisés par la UK Access Management Federation et l’ACOnet Identity Federation, auxquelles nous adressons nos remerciements.

1. Définitions et terminologie

Les expressions employées dans ce document ont le sens que voici.

  • Fédération : Fédération d’identités. Association d’organisations ayant pour objectif de garantir l’échange sécurisé d’informations concernant leurs ressources et leurs utilisateurs respectifs de manière à faciliter la collaboration et les transactions
  • Fédération participante/Participant : Organisation qui se joint à la Fédération en acceptant par écrit de respecter la politique de cette dernière
  • Exploitant de la Fédération : Organisation fournissant l’infrastructure servant à authentifier les participants de la Fédération et à leur conférer des autorisations
  • Politique de la Fédération : Document décrivant les obligations, les droits et les attentes des participants de la Fédération et de l’exploitant de la Fédération
  • Entité : Élément ponctuel que le participant souhaite inscrire et décrire dans les métadonnées; il s’agit habituellement d’un fournisseur d’identités ou de services
  • Registre : Système utilisé par l’exploitant de la Fédération pour  inscrire les métadonnées de l’entité; il peut s’agir d’un outil libre-service ou d’un procédé manuel quelconque
  • Représentant officiel : Personne autorisée à agir pour le compte du participant; son rôle peut varier, tout comme les pouvoirs qui s’y assortissent

2. Préambule et application

Ce document décrit les méthodes employées par l’exploitant de la Fédération pour inscrire  les métadonnées. Il entre en vigueur à la date de diffusion indiquée sur la page couverture. Les nouvelles entités inscrites à partir de cette date seront traitées de la manière décrite dans le présent document, jusqu’à ce qu’une nouvelle version l’annule et le remplace.

L’exploitant de la Fédération affichera ce document sur sa page Web ici. Les métadonnées des entités reflèteront fidèlement les modifications apportées à la documentation.

Les entités qui ne font pas référence à une politique d’inscription seront présumées avoir été enregistrées au moyen d’une pratique ancienne, que n’étaye aucune documentation. Une entité pourra être réévaluée en fonction d’une pratique courante d’inscription des données (MRPS – Metadata Registration Practice Statement) si on en fait la demande au service de dépannage de l’exploitant de la Fédération.

3. Admissibilité du participant et propriété

Le participant de la Fédération peut demander qu’on apporte des modifications à l’entité qu’il a inscrite dans le registre de l’exploitant de la Fédération en passant par son représentant officiel. Les demandes d’inscription émanant d’une autre source que le représentant officiel seront rejetées.

La procédure à suivre pour devenir participant de la Fédération est décrite à la page Web https://www.canarie.ca/fr/identite/adhesion/

La procédure usuelle consiste à s’assurer que le participant éventuel est autorisé par la loi à nouer une relation contractuelle avec  la Fédération et  à faire en sorte qu’il signe une  entente  de participation avec elle. L’exploitant effectue ces vérifications d’après le nom légal fourni.

Cette procédure permet aussi d’identifier et de vérifier les représentants officiels, c’est-à-dire les personnes qui peuvent agir au nom de l’organisation dans les transactions avec l’exploitant de la Fédération. Ces vérifications sont réalisées par prise de contact directe, par examen des relations antérieures entretenues avec CANARIE ou par consultation du répertoire électronique du personnel de l’organisation.

La procédure prévoit aussi la détermination du nom légal  du participant. Ce nom peut   toutefois changer durant la période d’adhésion, consécutivement à une modification du nom    de la société ou à une fusion,  par  exemple.  Le nom légal du  participant  est divulgué au moyen de l’élément <md:OrganizationName> de l’entité [SAML-Metadata-OS].

4. Format des métadonnées

Les métadonnées des entités inscrites par l’exploitant de la Fédération seront assorties d’une extension [SAML-Metadata-RPI-V1.0] indiquant que l’exploitant de la Fédération sert de registraire à l’entité et signalant la version du MRPS qui s’y applique. En voici un exemple, à titre d’illustration :

<mdrpi:RegistrationInfo 
registrationAuthority="http://www.canarie.ca" 
registrationInstant="2018-12-31T13:39:41Z">
<mdrpi:RegistrationPolicy xml_lang="en"> 
http://www.canarie.ca/doc/MRPS20181231</mdrpi:RegistrationPolicy>

5. Admissibilité et validation de l’entité

Inscription de l’entité

La façon dont le participant de la Fédération inscrit une entité est décrite à la page https://www.canarie.ca/fr/identite/adhesion/

L’exploitant de la Fédération s’assurera que le participant a le droit d’utiliser certains noms de domaine avec les attributs entityID.

Ce droit sera établi d’une des façons que voici :

  • le nom légal du participant correspond à l’information qui apparaît dans WHOIS;
  • une lettre du propriétaire du domaine autorise le participant à utiliser ce nom pour une entité donnée; on ne considérera pas que l’autorisation en question s’applique aux sous-domaines.

Format de l’attribut EntityID

Les valeurs de l’attribut entityID inscrit correspondront à un identifiant URI (Uniform Resource Identifier – identificateur uniforme de ressource) absolu, comme le veulent les schémas http, https ou urn.

Les participants devraient tous recourir aux URI du schéma https.

Les URI des schémas http et https employés comme valeur de l’attribut entityID intégreront une partie « hôte » ayant pour valeur un domaine DNS.

Format du champ d’application

Les fournisseurs d’identités intégreront le champ d’application à l’espace de nommage du domaine DNS, en minuscules. L’usage de plusieurs champs d’application est autorisé.

On pourra se servir d’expressions ordinaires pour indiquer les champs d’application, mais l’exploitant de la Fédération s’assurera que le participant a le droit d’utiliser les domaines DNS employés dans l’expression. Pour que l’exploitant de la Fédération puisse effectuer cette vérification, le jeu de domaines DNS inclus dans l’expression se terminera par un domaine à suffixe public, c’est-à-dire un point (« . ») suivi d’au moins deux étiquettes DNS également séparées par un point (« . ») – indiquant le domaine dont la propriété doit être validée par le propriétaire de l’entité – et se terminant par l’ancre « $ ». Exemple : (foo | bar).exemple.com$).

Validation de l’entité

Lors de l’inscription, l’exploitant de la Fédération valide l’entité en procédant comme suit :

  • il s’assure que les informations requises figurent dans les métadonnées;
  • il s’assure que les métadonnées sont formatées de la manière appropriée;
  • il s’assure que les points d’extrémité du protocole sont bien protégés par un certificat TLS / SSL

Gestion des entités

Après l’adhésion du participant, il se peut que l’organisation ajoute, modifie ou supprime diverses entités.

Demande de modification

Le participant qui souhaite  ajouter, modifier ou  supprimer une entité en fera  la  demande par le biais de son représentant officiel ou ce dernier confirmera l’exactitude de la demande.

Les contacts désignés signalent les changements éventuels par courriel à [email protected].

Modifications non sollicitées à l’entité

L’exploitant de la Fédération peut apporter des modifications aux métadonnées de la Fédération en tout temps dans les situations que voici :

  • pour garantir la sécurité et l’intégrité des métadonnées;
  • pour se conformer aux ententes conclues entre fédérations;
  • pour améliorer l’interopérabilité;
  • pour bonifier les métadonnées.

Ces changements seront communiqués au représentant officiel responsable des entités concernées.

References

> [RFC2119]: Bradner, S., « Key words for use in RFCs to Indicate Requirement Levels », BCP 14, RFC 2119, March 1997.
> [SAML-Metadata-RPI-V1.0]: SAML V2.0 Metadata Extensions for Registration and Publication Information Version 1.0. 03 April 2012. OASIS Committee Specification 01. http://docs.oasis- open.org/security/saml/Post2.0/saml-metadata-rpi/v1.0/cs01/saml-metadata-rpi-v1.0-cs01.html.
> [SAML-Metadata-OS]: OASIS Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0: http://docs.oasis- open.org/security/saml/v2.0/saml-metadata-2.0-os.pdf.