La fédération d'identité au travers de SAML

Normalisé par l'OASIS, SAML permet l'échange sécurisé d'informations d'identités. Il définit un format du message XML, appelé assertion, ainsi qu'un ensemble de profils.

Ce billet a pour vocation de présenter la fédération d'identité en s'appuyant sur le protocole SAML 2.0. Un futur billet présentera le logiciel Shibboleth, implémentation Open Source de référence de cette norme.

SAML 2.0

Normalisé, dans sa version 2.0, en mai 2005 par l'OASIS, SAML permet l'échange sécurisé d'informations d'identités (authentification et autorisation). SAML définit le format du message XML, appelé assertion, ainsi qu'un ensemble de profils. Ces profils sont des cas d'utilisation détaillés qui présentent la cinématique d'échange des messages, les paramètres attendus et renvoyés.

Fonctionnement

SAML définit deux briques essentielles pour sécuriser les échanges :

 Le SP (Service Provider), fournisseur de service, protège l'accès aux applications. Il refuse tout accès sans authentification préalable et redirige l'utilisateur non authentifié vers son fournisseur d'identité.

 L'IdP (Identity Provider), fournisseur d'identité, s'occupe d'authentifier l'utilisateur ainsi que de récupérer des informations additionnelles associées à son identité.

Ce mode de fonctionnement est suffisant pour une utilisation cantonnée à l'entreprise avec un annuaire des identités centralisé.

Dans le cadre d'une fédération entre plusieurs domaine d'identification, SAML définit une troisième brique appelée le DS (Discovery Service) qui permet à l'utilisateur de sélectionner manuellement son domaine parmi une liste. Avec un peu de configuration, il est possible de supprimer cet élément, un peu bloquant pour les utilisateurs.

Profils

Le profil le plus courant, appelé "Web Browser SSO", décrit, entre autres, les étapes d'authentification d'un utilisateur et les allers-retours entre le SP et l'IdP. L'utilisateur tente d'accéder à sa ressource protégée par le SP. Le SP vérifie que l'utilisateur est authentifié et s'il ne l'est pas, le redirige vers son IdP. L'IdP demande à l'utilisateur de s'authentifier (identifiant puis mot de passe par exemple) puis renvoie une assertion SAML au SP contenant l'identité de l'utilisateur et la garantie qu'il est authentifié. Le SP autorise alors l'utilisateur à accéder à la ressource initialement demandée.

Ce mécanisme d'authentification repose sur les redirections du navigateur Internet. Ce profil permet aussi de récupérer un ensemble d'attributs supplémentaires liés à l'identité de l'utilisateur et demandés par la ressource.

Un second profil basé sur des artéfacts, permet de décorréler l'authentification de la récupération des informations d'identité de l'utilisateur. Le SP reçoit de l'IdP, par le navigateur Internet de l'utilisateur, une assertion SAML contentant un artefact. Le SP doit alors interroger directement l'IdP pour obtenir les informations liées à l'identité de l'utilisateur.

D'autres profils décrivent comment mettre en œuvre le DS, les notions de logout et la possibilité de se passer du navigateur de l'utilisateur pour transmettre les assertions SAML entre services.

Sécurité

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.

Conclusion

Ce protocole est donc très sécurisé, et remplit parfaitement les fonctions de SSO au sein d'une entreprise et entre différents domaines d'identification. Il devrait, à mon sens, remplacer les logiciels propriétaires de Web SSO, beaucoup moins sécurisés.

Thierry Albain est consultant au sein de la société de services SQLI