Click here for the english version
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:
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 :
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.
Ces méta-données sont ensuite mise à disposition par deux moyens différents:
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 resources pour résoudre ces problèmes: si l'algorithme de validation n'est pas parallélisable, par exemple, augmenter le nombre de coeurs CPU disponibles ne changera pas grand chose.
Dans le cas de RENATER, ces fichiers de métadonnées sont disponibles en plusieurs versions, en fonction du type d'entité, et du niveau de maturité souhaité. Pour plus de détails, voire cette page dédiée.
Ces fichiers sont également signés numériquement, de façon à assurer leur intégrité, en plus de la sécurité assurée par le canal de transport. Pour pouvoir vérifier la signature des fichiers de métadonnées, vous devez télécharger ce certificat X.509, et éventuellement vérifier son empreinte:
$ /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
Enfin, 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.
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é.
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.
<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>
<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>
Si vous n'utilisez pas les implémentations de référence de RENATER (Shibboleth et SWITCH WAYF), nous vous recommandons de vérifier l'interopérabilité de votre implémentation SAML avec notre format de méta-données SAML2 via la fédération de test dans un premier temps. Si le problème persiste, tournez-vous vers les développeur du logiciel.
Si vous utilisez Shibboleth ou SWITCH WAYF, signalez-nous le problème rencontré. Le logiciel Shibboleth gère une copie locale des fichiers de méta-données qui sera utilisée, faute de pouvoir en charger une version à jour ; cette version locale du fichier de méta-données est exploitable pendant 9 jours.
La vérification de la signature des méta-données SAML publiées par RENATER utilise l'algorithme de hashage SHA-256. Cet algorithme est géré par OpenSSL 0.9.8 (et versions plus récentes) et Java 4 (et versions plus récentes). Si votre implémentation SAML n'est pas capable de vérifier la signature des méta-données SAML, vérifiez la version de la bibliothèque OpenSSL et éventuellement contactez le support du logiciel SAML concerné. Voir la documentation Shibboleth IdP signature interoperability issues du consortium Shibboleth.
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 ou 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 noeuds, 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.
Enfin, les métadonnées fournies via ce protocole ne sont pour l'instant pas signées, l'intégrité étant assurée par le canal de transport uniquement (TLS).
Le serveur MDQ opéré par RENATER propose plusieurs points d'accès, en fonction de la fédération souhaitée:
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).
Cette fois-ci, le certificat configuré est celui de l'autorité de certification ayant délivré le certificat du serveur MDQ.
<MetadataProvider xsi:type="DynamicHTTPMetadataProvider" persistentCacheManagerDirectory="/opt/shibboleth-idp/metadata/fer" httpClientSecurityParametersRef="HttpSecurityParameters"> <MetadataQueryProtocol>https://mdq.federation.renater.fr/fer</MetadataQueryProtocol> </MetadataProvider> <!-- https://shibboleth.atlassian.net/wiki/spaces/IDP4/pages/1265631724/HttpClientConfiguration#PKIX-verification-with-root-CA --> <bean id="HttpSecurityParameters" class="org.opensaml.security.httpclient.HttpClientSecurityParameters"> <property name="tLSTrustEngine"> <bean parent="shibboleth.StaticPKIXTrustEngine" p:certificates="/etc/pki/tls/certs/usertrust_rsa_certification_authority.crt" p:checkNames="false"/> </property> </bean>
<MetadataProvider type="MDQ" baseUrl="https://mdq.federation.renater.fr/fer" cacheDirectory="fer"> <TrustEngine type="StaticPKIX" certificate="/etc/pki/tls/certs/usertrust_rsa_certification_authority.crt"/> </MetadataProvider>
