Click here for the english version

Méta-données SAML publiées par RENATER

RENATER publie des méta-données SAML dans le cadre de son infrastructure de fédération d'identité. Ces méta-données recensent les informations techniques sur les fournisseurs d'identité (IdP) et les fournisseurs de service (SP) renseignées au travers du guichet de la fédération.

Ces méta-données sont indispensable au fonctionnement d'une fédération d'identité, puisque les entités SAML doivent se connaitre mutuellement avant d'échanger le moindre message. L'authentification réciproque, par exemple, nécessite que chacun connaisse le certificat de signature de l'autre. En conséquence, pour pouvoir communiquer avec une autre entité enregistrée dans une fédération d'identité, une entité doit:

  • être enregistrée dans cette fédération d'identité, de façon à être présent dans les méta-données chargées par les autres
  • charger les méta-données de cette même fédération d'identité, de façon à connaitre les autres

L'enregistrement dans une fédération, via le guichet, ne constitue que la première partie de cette relation de confiance symétrique, et doit être complétée par une modification de la configuration.

RENATER gère plusieurs cercles de confiance et publie des méta-données pour chacune de ces fédérations :

  • la Fédération Éducation-Recherche (plus d'infos) : l'environnement de production pour la communauté éducation-recherche française ;
  • La fédération de qualification (plus d'infos) : l'environnement de qualification pour la communauté éducation-recherche française, dont les conditions sont proches de la Fédération Éducation-Recherche, sans pour autant polluer celle-ci avec des services non pertinents.
  • L'inter-fédération eduGAIN (plus d'infos) : l'environnement de production pour la communauté éducation-recherche internationale. Les données publiées proviennent de GEANT, opérateur de eduGAIN ;
  • Les fédérations locales (plus d'infos) : des environnements de production pour des groupes d'établissements éducation-recherche français. L'URL des méta-données des fédérations locales n'est pas publique ;
  • La fédération de test (plus d'infos) : l'environnement de test pour les organismes éducation-recherche, en accès libre.

Le service des comptes CRU est un service d'authentification complémentaire proposé par RENATER. Ce fournisseur d'identité n'est inscrit dans aucune fédération, mais vous pouvez télécharger ses méta-données individuellement.

Les méta-données d'une fédération sont construites à partir des informations techniques fournies par les administrateurs des IdP/SP via le guichet de la fédération. L'enregistrement d'un SP/IdP dans une fédération de production sont soumis à validation par les responsables fédération désignés par l'organisme (membre ou partenaire) dont vous dépendez.

L'accès au guichet de la fédération requiert une authentification. Si vous n'avez pas (encore) un fournisseur d'identité enregistré dans la Fédération Éducation-Recherche, vous devez au préalable créer votre compte CRU.

Les méta-données font l'objet d'un processus de mise à jour automatique, à partir des données saisies dans le guichet de la fédération. Ce processus prend en charge la validation du format des méta-données, l'agrégation de données externes (cas d'eduGAIN) et la signature cryptographique des fichiers.

L'intégrité de ces métadonnées est assurée par deux mécanismes distincts:

  • l'utilisation d'un canal de transport sécurisé (via TLS)
  • l'utilisation d'une signature cryptographique

Contrairement à beaucoup d'autres logiciels, ni l'IdP si le SP Shibboleth ne vérifient par défaut le certificat présenté par le serveur d'origine, le premier mécanisme est donc inopérant. Il reste possible de le faire, en jouant sur les options de la couche transport. La vérification de la signature, quand à elle, nécessite de récupérer d'abord le certificat de signature, de vérifier son empreinte (voir ci-dessous), puis de configurer un filtre adéquat.

$ /usr/bin/curl -O https://pub.federation.renater.fr/metadata/certs/renater-metadata-signing-cert-2016.pem 
$ /usr/bin/openssl x509 -sha256 -noout -fingerprint -in renater-metadata-signing-cert-2016.pem
SHA256 Fingerprint=6B:D3:5F:7A:B1:64:EC:79:03:0D:36:97:BA:40:BD:23:5D:AA:DA:C0:43:47:C6:E5:3E:B7:72:A7:74:2C:16:5F

Ces méta-données sont ensuite mise à disposition par deux moyens différents:

  • sous forme de fichiers XML
  • via le protocole MDQ (Metadata Query Protocol)

Principe

Les fichiers XML correspondent à la façon classique de distribuer des méta-données SAML. Ils ont l'avantage de la robustesse, et de la simplicité, mais le passage à l'échelle pose problème. En effet, ce mode de distribution consiste à télécharger systématiquement les méta-données de toutes les entités avec lesquelles existe une relation de confiance, même si elles ne sont jamais utilisées. Avec une fédération internationale comme edugain, qui compte aujourd'hui près de 9000 entités SAML, et dont la taille ne cesse d'augmenter, on atteint souvent des limites en terme d'empreinte mémoire, ou de temps de validation des signatures cryptographiques. Et il ne suffit pas forcément d'allouer plus de ressources pour résoudre ces problèmes: si l'algorithme de validation n'est pas parallélisable, par exemple, augmenter le nombre de cœurs CPU disponibles ne changera pas grand chose.

Ces fichiers ont une durée de validité de 9 jours: même en cas d'indisponibilité temporaire de la source des métadonnées, une entité SAML sera capable de fonctionner pendant ce délai.

Quels fichiers utiliser ?

Selon le type d'entité SAML que vous gérez et les fédérations dans laquelle elle est enregistrée, vous devez charger des fichiers de méta-données différents. Pour plus de détails, voire cette page dédiée.

Nous recommandons de planifier cette synchronisation toutes les heures, même si la fréquence de publication habituelle des méta-données n'est que quotidienne, afin de garantir une prise en compte rapide en cas de modifications urgentes de notre coté.

Exemples de configuration

Les exemples ci-dessous gèrent le chargement des méta-données de la Fédération Éducation-Recherche. Vous devrez les adapter pour les autres fédérations (eduGAIN, test, fédérations locales).

Dans les deux cas, le certificat configuré correspond à celui utilisé pour signer les métadonnées. Il n'est pas nécessaire de renseigner l'autorité de certification du certificat du serveur, parce que par défaut, le l'IdP et le SP n'effectuent aucune vérification de celui-ci.

IdP Shibboleth IdP 3.x/4.x (cliquer pour déplier)
IdP Shibboleth IdP 3.x/4.x (cliquer pour déplier)
metadata-providers.xml
<MetadataProvider xsi:type="FileBackedHTTPMetadataProvider"
    metadataURL="https://pub.federation.renater.fr/metadata/renater/main/main-sps-renater-metadata.xml"
    backingFile="%{idp.home}/metadata/fer.xml"> 
    <MetadataFilter xsi:type="SignatureValidation"
        requireSignedRoot="true"
        certificateFile="%{idp.home}/credentials/renater-metadata-signing-cert-2016.pem">
    </MetadataFilter>        
</MetadataProvider>
SP Shibboleth SP 3.x (cliquer pour déplier)
SP Shibboleth SP 3.x (cliquer pour déplier)
shibboleth2.xml
<MetadataProvider type="XML"
    url="https://pub.federation.renater.fr/metadata/renater/main/main-idps-renater-metadata.xml"
    backingFilePath="fer.xml" reloadInterval="3600">
    <MetadataFilter type="Signature" certificate="renater-metadata-signing-cert-2016.pem"/>
</MetadataProvider>

Problèmes potentiels

La taille de certains fichiers de métadonnées, et notamment ceux de la fédération eduGAIN, les rend incompatibles avec certaines implémentatations, notamment Azure Enterprise Application.

Le protocole MDQ consiste à interroger à la volée un serveur dédié pour lui demander les méta-données d'une entité spécifique, et uniquement lorsque celles-ci sont vraiment nécessaire, c'est-à-dire au moment de la demande d'accès. Par rapport au cas précédent, ceci représente une forte économie de ressources (réseau, stockage, mémoire), surtout lorsque très peu de services sont effectivement utilisés. En revanche, les contraintes de disponibilités sont beaucoup plus forte: si le serveur MDQ n'est pas disponible au moment où un utilisateur tente de se connecter au service, celui-ci sera incapable de produire une demande (ou une réponse) d'authentification.

Il s'agit d'un service redondé, configuré pour répartir la charge sur plusieurs nœuds, mais hébergé sur un seul site: en cas d'indisponibilité de celui-ci, le service ne sera donc pas disponible, ce qui constitue potentiellement un point unique de défaillance, par contraste avec le système précédent. Il faut néanmoins relativiser cette fragilité, puisque c'est également vrai pour l'ensemble de nos services, dont le service de découverte (https://discovery.renater.fr) dont dépendent déjà beaucoup de fournisseurs de service.

Quelles URLs utiliser ?

Le serveur MDQ opéré par RENATER propose plusieurs points d'accès, en fonction de la fédération souhaitée:

Exemples de configuration

Les exemples ci-dessous gèrent le chargement des méta-données de la Fédération Éducation-Recherche. Vous devrez les adapter pour les autres fédérations (eduGAIN, test, fédérations locales).

IdP Shibboleth IdP 3.x/4.x (cliquer pour déplier)
IdP Shibboleth IdP 3.x/4.x (cliquer pour déplier)
metadata-providers.xml
<MetadataProvider xsi:type="DynamicHTTPMetadataProvider"
    persistentCacheManagerDirectory="/opt/shibboleth-idp/metadata/fer">
    <MetadataFilter xsi:type="SignatureValidation"
        requireSignedRoot="true"
        certificateFile="renater-metadata-signing-cert-2016.pem">
    </MetadataFilter>
    <MetadataQueryProtocol>https://mdq.federation.renater.fr/fer</MetadataQueryProtocol>
</MetadataProvider>
SP Shibboleth SP 3.x (cliquer pour déplier)
SP Shibboleth SP 3.x (cliquer pour déplier)
shibboleth2.xml
<MetadataProvider type="MDQ"
    baseUrl="https://mdq.federation.renater.fr/fer"
    cacheDirectory="fer">
    <MetadataFilter type="Signature" certificate="renater-metadata-signing-cert-2016.pem"/>
</MetadataProvider>

Plus de détails

  • federation/documentation/generale/metadata/index.txt
  • Dernière modification : 2024/06/27 11:59
  • de ludovic.auxepaules@renater.fr