Click here for the english version

Utilisation des certificats électroniques dans une fédération d'identité SAML

Les briques IdP et SP utilisent des certificats électroniques pour plusieurs usages distincts:

  • pour sécuriser les échanges HTTP, entre le navigateur de l'utilisateur et le serveur web qui héberge chacune de ces deux parties
  • pour sécuriser les échanges LDAP, entre l'IdP et l'annuaire
  • pour sécuriser les échanges SAML, entre l'IdP et le SP
  • pour vérifier l'authenticité des métadonnées publiées par l'opérateur

Si les contraintes liées aux deux premiers cas (protocole TLS) sont classiques, et ne seront pas rappelées ici, les contraintes liées aux autres cas le sont beaucoup moins, notamment parce que le modèle de sécurité n'a rien à voir. En effet, le modèle hiérarchique des tiers de confiance (les autorités de certifications), qui signent les certificats pour assurer leur authenticité, n'est pas utilisé, et remplacé par un tiers de confiance unique, l'opérateur de la fédération, qui publie l'ensemble des certificats de chaque entité dans les métadonnées de cette fédération. Un certificat auto-signé a donc autant de valeur qu'un certificat fourni par une autorité de certification dans ce contexte, sans les contraintes liées à la durée de validité de surcroit.

Dans le cas des fédérations d'identité gérée par Renater, et notamment la Fédération Education/Recherche, cette publication se fait au travers du guichet de la fédération.

1. Sécurisation des échanges SAML : principe

La sécurisation des échanges SAML est caractérisée par les opérations suivantes :

  • La signature des assertions SAML. Elle permet au destinataire d’une assertion SAML de s’assurer de l’identité de l’émetteur de l’assertion ainsi que d’en vérifier l’intégrité. Cette opération est effectuée par les deux parties impliquées dans l’échange (IDP et SP).
  • Le chiffrement des assertions SAML. Via l’utilisation du certificat du destinataire pour chiffrer l’assertion, l’émetteur s’assure que seul le destinataire concerné puisse accéder au contenu de l’assertion. Cette opération est effectué par défaut par l’IDP. Elle est en revanche très rarement mise en oeuvre côté SP (sauf cas d'usage spécifique).

La réalisation de ces deux opérations (signature et chiffrement) se basent sur l’utilisation des certificats SAML de chacune des parties publiés dans les métadonnées de la fédération.

Le tableau suivant résume les opérations effectuées par chaque entité (IDP et SP) et le support cryptographique utilisé :

Entité SAML Sens de l'échange Opérations Support utilisé
IDP IDP vers SP Signature assertion SAML Clé privée IDP
IDP vers SP Chiffrement assertion SAML Certificat SP publié dans métadonnées
SP vers IDP Vérification signature SP assertion SAML Certificat SP publié dans métadonnées
SP SP vers IDP Signature assertion SAML Clé privée SP
IDP vers SP Déchiffrement assertion SAML Clé privée SP
IDP vers SP Vérification signature IDP assertion SAML Certificat IDP publié dans métadonnées



2. Recommandations RENATER pour les certificats SAML

RENATER recommande très fortement l’utilisation de certificats auto-signés pour la couche SAML car les autorité de certification sont totalement ignorées dans ce contexte, et leur longévité facilite la configuration, la maintenance des briques techniques SAML et diminue les risques de problèmes d’interopérabilité avec des implémentations SAML2 différentes (cas d’une inter-fédération par exemple).

Important : Tous les certificats nouvellement déclarés via le guichet de la fédération devront respecter les caractéristiques mentionnées ci-après.

Les certificats utilisés pour la couche SAML doivent en particulier respecter les 2 caractéristiques suivantes:

  1. Une durée de vie longue (10 ans ou plus). Une longue durée de vie évite en effet des actions de renouvellements fréquents.
  2. Seules des clés de taille de 2048 bits minimum doivent être utilisées. Des tailles supérieures ne sont pas conseillées pour ne pas pénaliser les briques techniques lors des phases de chiffrement et signature.

Notes techniques:

  • Dans le cas de l'utilisation de profils SAML2 SOAP, il est nécessaire de faire concorder le hostname du serveur avec le CN du certificat ;
  • Certaines implémentations SAML2 comme ADFS n'autorisent pas l'association d'un même certificat pour deux entités différentes.
  1. La confiance dans ces certificats provient du fait qu'ils sont collectés, vérifiés et associés à leurs entités SAML respectives via le guichet de la Fédération Éducation-Recherche. Ces informations sont ensuite publiées dans les méta-données elles-mêmes signées par l'opérateur de fédération et accessibles via une URL en HTTPS, permettant ainsi d’en garantir l'intégrité et l'origine
  2. Tout certificat expiré ou utilisant une taille de clé ou un algorithme de chiffrement considéré comme trop faible doit être remplacé et supprimé une fois le renouvellement de certificat effectué ;
  3. Si la clé privée devait être compromise, les gestionnaires de l'entité SAML doivent immédiatement générer un nouveau biclé et remplacer promptement la clé publique de l'entité SAML. Il est nécessaire de prévenir les gestionnaires de la fédération afin que l'opération soit la plus rapide possible.


3. Procédures à destination des administrateurs d'IDP/SP

Les administrateurs d'IdP et/ou SP peuvent se référer aux procédures suivantes pour les opérations courantes impliquant la manipulation du certificat SAML de leur entité :

Si vous administrez un IdP :

Si vous administrez un SP :


  • federation/documentation/generale/certificats-saml.txt
  • Dernière modification : 2023/12/06 13:33
  • de guillaume.rousse@renater.fr