Quels sont les enjeux des certificats électroniques dans la fédération d’identités ?

On assiste aujourd’hui à une véritable montée des attaques informatiques qui ont pour objectifs des atteintes à la protection des données personnelles et des usurpations d’identités. En effet dans une course à la performance et aux accès instantanés à l’information, les utilisateurs ne sont pas très souvent conscients des risques de sécurités liés à leurs actions. 

La fédération d’identité répond à cette problématique. Elle donne aux utilisateurs le moyen de naviguer entre différents services en leur évitant ainsi, les contraintes d’inscription et d’authentification. Grâce à la fédération d’identité, l’utilisateur s’authentifie une seule fois, avec divers facteurs d’authentification, auprès d’un tiers de confiance, garant de leurs identités.  

Cette fédération est possible grâce à des règles de gouvernance. Elles spécifient comment les différents acteurs (utilisateur, SP, IdP) s’échangent les informations d’identités donnant ainsi naissance à une relation de confiance. 

Cette relation est assurée par différents protocoles : SAML2, OpenID Connect (OIDC), WS-Fed …. 

Ces protocoles utilisent des certificats numériques pour vérifier l’authenticité et l’intégrité des échanges entre le fournisseur d’identité (IdP) et le fournisseur de services (SP). 

Protocoles de fédération d’identité

Dans le cadre de cet article nous porterons notre étude sur SAML et OIDC qui sont les deux protocoles les plus répandus. 

Protocole SAML2 

SAML (Security assertion markup language) est un protocole d’authentification basé sur le XML et développé par OASIS (Organization for the Advancement of Structured Information Standards) pour les communications normalisées entre IdP, SP et utilisateurs finaux. Les assertions SAML peuvent être signées et chiffrées. 

Les communications entre un IdP et un SP à travers ce protocole suivent des étapes spécifiques : 

1. Un utilisateur veut se connecter à un service protégé de son entreprise à partir de son navigateur web. 
2. Le service provider (SP) fait une redirection vers le fournisseur d’identité avec une requête d’authentification de type SAML.
3. L’IdP demande à l’utilisateur d’entrer ses informations de connexion.
4. L’utilisateur s’authentifie.
5. Le fournisseur d’identité va analyser la demande et générer une réponse SAML qui prouvera l’identité (fichier XML appelé «token» ou «jeton») de l’utilisateur.
6. Le SP va analyser la réponse et si la vérification réussit, l’utilisateur est connecté à l’application.

Protocole OpenID Connect 

OIDC est l’évolution du standard OpenID qui s’appuie sur le protocole OAuth en y ajoutant une couche d’authentification. Il repose sur le standard JSON Web Token (JWT) pour l’échange des informations d’identités ou toutes autres informations entre le RP (relying party) qui est en réalité le fournisseur de service et l’IdP. De manière similaire aux assertions SAML, ces jetons peuvent être signés ou même chiffrés. 

Le principe de fonctionnement de ce protocole est le suivant : 

1.  L’utilisateur veut se connecter à une application à travers son navigateur. 
2. Il est redirigé par celle-ci vers le serveur d’authentification.
3. L’utilisateur s’authentifie à travers un facteur d’authentification spécifique. 
4. Le serveur d’authentification va envoyer un code d’autorisation au navigateur web de l’utilisateur. 
5. Ce code est communiqué à l’application. 
6. Le code est envoyé de l’application vers le serveur d’authentification pour obtenir en échange un jeton d’identité (jeton au format JWT).  
7. Le jeton d’identité est transmis à l’application. Celle-ci a donc la garantie de la part du serveur d’authentification que l’utilisateur peut accéder à l’application.

Différence entre SAML2 et OIDC  

Les certificats dans la fédération d’identité 

La fédération d’identité est une association entre fournisseurs de service (SP) et fournisseurs d’identité (IdP) de différents domaines de sécurité. Cette association s’appuie sur les certificats pour vérifier l’authenticité et l’intégrité des messages échangés entre ces deux entités (IdP, SP). En plus de cela, les certificats sont utilisés pour sécuriser les échanges HTTP, entre le navigateur de l’utilisateur et les serveurs web qui hébergent chacune de ces deux parties (les contraintes liées à cet usage sont classiques, et ne seront pas rappelées ici). 

Enjeux des certificats dans SAML 

La sécurisation des échanges SAML entre l’IdP et le SP 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ée par défaut par l’IDP. Elle est en revanche très rarement mise en œuvre côté SP (sauf cas d’usage spécifique). 

Le tableau suivant résume les opérations généralement effectuées par chaque entité (IdP, SP) : 

Enjeux des certificats dans OpenID Connect 

Pour ce qui est du protocole OIDC, on peut utiliser les certificats pour vérifier l’intégrité du jeton JWT et aussi pour s’assurer de l’identité de l’émetteur. Un JWT signé doit être conforme au standard JWS (JSON Web Signature, RFC 7515). 

Le JWT peut être signé en utilisant un secret (avec l’algorithme HMAC) ou une paire de clés publiques/privées en utilisant RSA. Dans la deuxième utilisation le fournisseur de services doit être en possession du certificat correspondant à la clé privée avec laquelle la signature fut élaborée. 

La fédération d’identité dans la solution BerryCert 

Afin de répondre aux problématiques actuelles en termes de gestion des identités, la solution BerryCert offre à ses utilisateurs la possibilité de s’interfacer avec un Fédérateur d’Identité en supportant les deux protocoles SAMLv2 et OIDC. En outre, BerryCert implémente aussi des mécanismes pour la gestion automatisée des certificats mis en jeu par ces deux protocoles.