La fédération d’identité

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éfini 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ées 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 pourvoir 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 chacun l’un de l’autre en terme 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.