Qu’est-ce que la fédération d’identité?

Déroulez ici

Aujourd’hui, que ce soit dans le monde professionnel ou simplement privé, sur le web par exemple, nous ne cessons de devoir nous authentifier et saisir des mots de passe différents pour chaque application ou  services. Face à  ces “tracasseries de sécurité”, la fédération d’identité apporte  une solution efficace  en propageant l’authentification de manière transparente entre  applications.


Pour m'offrir un café en échange du travail de veille réalisé gratuitement

Le principe de la fédération d’identité

Pour rappel, une personne (un être humain) possède en théorie pour chaque écosystème (entreprise, maison, …) une identité informatique unique. Il s’agit habituellement d’un code, une clé, qui lui permet d’être identifié de manière unique : Bob, MaxL456, User-145, …

Au niveau de chaque application, nous disposons habituellement d’un code personnel, l’identifiant, qui peut être le même que celui de l’identité mais pas obligatoirement. Combiné à  un mot de passe, ou un autre challenge comme de la biométrie par exemple, cet identifiant permet d’authentifier cette identité.

Comme mentionné en introduction, le problème que nous rencontrons est la multiplication des authentifications nécessaires pour les  applications auxquelles nous souhaitons  accéder. Au final, nous devons accumuler les informations relatives à  notre identité et encore, pour chaque application, l’identifiant et le mot de passe associés:

Avec le web et même dans le monde de entreprises, cette explosion du nombre d’authentification est un réel problème qui pousse souvent à  des comportements déviants comme celui d’utiliser un même mot de passe pour toutes nos applications ou de créer des fichiers de mots de passe  … et c’est ici que la fédération d’identité tire  son épingle du jeu  en proposant qu’une authentification suffise et que cette information soit ensuite propagée vers d’autres applications pour éviter de devoir à  chaque fois resaisir les login et mot de passe.

Le principe de fédération d’identités

Ainsi, après une première authentification réussie, un mécanisme (protocole) de confiance se met en place pour informer l’autre application de qui vous êtes et que l’authentification est valable car il l’a déjà  été vérifiée. Le Single-Sign-On (SSO) en est un exemple typique de mise en pratique qui permet,par exemple dans votre entreprise, d’accéder directement à  votre messagerie en ayant uniquement saisi au départ votre identifiant-mot de passe de Windows.

Les protocoles  de propagation et de fédération d’identité

Ce principe de SSO, en utilisant des cookies sur le web par exemple, est aujourd’hui  très utilisé et se base souvent  sur l’authentification fournie initialement sur un réseau social avec Facebook ou Twitter par exemple.

Le principal mécanisme de fédération est aujourd’hui le  Security assertion markup language (SAML)  qui est un standard informatique définissant un protocole pour échanger des informations d’authentification, sans pour autant que ces sites web ou applications aient accès à  des informations trop sensibles.

Dans ce cas, l’application initiale, appelée fournisseur de service (ou SP pour Service Provider), délègue l’authentification de l’utilisateur à  Facebook ou Twitter qui sont les  fournisseurs d’identité (ou IdP pour Identity Provider). Un fournisseur de services peut donc faire appel à  plusieurs fournisseurs d’identité comme le montre cet exemple et le contraire est également valable.

Lors de la phase suivante (voir copie d’écran ci-dessous), on retrouve alors effectivement ces informations soit:

  1. Le fournisseur d’identité, ici Twitter pour cet exemple
  2. Le fournisseur de service, Storify auquel nous souhaitons accéder en utilisant
  3. Les informations d’authentification (login et mot de passe) de Twitter pour accèder au service de Storify (qui sera stocké dans des cookies pour une authentification directe les prochaines fois) et
  4. Les informations relatives aux autorisations qui être octroyée à  l’utilisateur après l’authentification.

D’un point de vue technique, SAML définit le format des échanges de messages au format XML, appelé les assertions. Il décrit également les cas d’utilisation en y précisant les  échange des messages ainsi que les paramètres  envoyés et reçus. De manière complémentaire, les relations de confiance techniques entre les fournisseurs s’appuient sur des certificats  qui permettent ainsi de garantir des communications sécurisées entre eux.

Les assertions SAML sont basées sur les couches SOAP, XML Encryption et XML Signature.

  • SOAP est le protocole d’encapsulation standard des messages XML, utilisé principalement par les Web services.
  • XML Encryption est le protocole standard de chiffrement des messages XML. Il a la particularité de pouvoir chiffrer la globalité du message ou simplement un sous-ensemble précis. Cela permet d’avoir par exemple un document XML en clair avec des valeurs d’attributs chiffrées.
  • XML Signature est le protocole standard de signature des messages XML. Tout comme XML Encryption il permet de cibler l’élément à  signer. Cela permet à  plusieurs intervenants de signer chacun une partie différente du document XML.

Le SP et L’IdP sont deux entités qui ont connaissance chacune l’une de l’autre en termes d’identifiant et de certificat. Les messages XML qui transitent sur le réseau sont donc chiffrés par la clé publique du destinataire, seul capable de déchiffrer le message avec sa clé privée. L’émetteur signe ses assertions avec sa clé privée permettant au destinataire de vérifier sa provenance.

via  La fédération d’identité au travers de SAML – JDN Web & Tech.

Dans le cas du web, voici une illustration des différents échanges de messages permettant de propager l’identité  :

Source : La fédération d’identité : nouvel enjeu pour le SSO | BeeWebsec.

4 Comments

Laisser un commentaire

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.

La newsletter