Alors que les systèmes de SSO au sein des organisations sont largement répandus, on cherche aujourd’hui à les étendre vers l’extérieur, vers les organismes et services partenaires, et vers les SaaS. Il s’agit avant tout d’une démarche de simplification pour l’utilisateur, lui évitant une multitude de saisies et de créations de comptes. Elle permet d’autre part aux sites partenaires, susceptibles d’utiliser des systèmes potentiellement faillibles, de déléguer l’authentification d’un utilisateur au système d’authentification forte, centralisé et maitrisé par le SI de l’organisme. Par Claude-Jacques Tronquet, Developpeur IAM Bee Ware.

Alors que les systèmes de SSO au sein des organisations sont largement répandus, on cherche aujourd’hui à les étendre vers l’extérieur, vers les organismes et services partenaires, et vers les SaaS. Il s’agit avant tout d’une démarche de simplification pour l’utilisateur, lui évitant une multitude de saisies et de créations de comptes. Elle permet d’autre part aux sites partenaires, susceptibles d’utiliser des systèmes potentiellement faillibles, de déléguer l’authentification d’un utilisateur au système d’authentification forte, centralisé et maitrisé par le SI de l’organisme. Cette délégation est particulièrement critique pour les entreprises. A cela s’ajoute la gestion de l’identité numérique et de la diffusion des informations nominatives des utilisateurs. Ces problématiques s’articulent autour de la fédération d’identités.

L’externalisation de cette fédération d’identité entraine généralement une réduction de coûts, et surtout propose une base solide aux entreprises leur permettant un accroissement du chiffre d’affaire du fait de l’élargissement du spectre des services apportés au client. La fédération est, en effet, un moyen puissant et sûr de mettre les ressources d’autres compagnies à la disposition de l’entreprise et vice-versa.

Les solutions de fédération d’identités permettent à une application, dans un organisme, d’interagir avec un système d’authentification d’une autre entité. L’application, appelée « fournisseur de service » (ou SP, Service Provider), délègue la phase d’authentification d’un utilisateur à l’organisme auquel il est rattaché, appelé « fournisseur d’identité » (ou IdP, Identity Provider). Le SP conserve la prérogative du contrôle d’accès, mais peut pour cela utiliser des attributs de l’utilisateur fournis par l’IdP. Un SP peut être sollicité par des utilisateurs issus de différents IdP. Inversement, les utilisateurs rattachés à un IdP peuvent accéder à différents SP.

SAML comme format d’échange

Dans le contexte professionnel, la fédération d’identités se repose sur SAML (Security Assertion Markup Language, normalisé, dans sa version 2.0, en mai 2005 par l’OASIS) comme standard pour le format des assertions d’authentification et d’attributs entre les IdP et les SP. 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. Toutes les solutions de fédération d’identités s’appuient sur des techniques de base employées par les SSO : redirections HTTP, cookies, Web services, SSL. Les relations de confiance techniques entre les fournisseurs s’appuient généralement sur des certificats x509 ou des clés symétriques. Plusieurs spécifications de frameworks de fédération d’identité sont aujourd’hui disponibles (cette multiplicité n’en facilite d’ailleurs pas son adoption): ID-FF de Liberty Alliance et Shibboleth d’Internet2 (qui est à l’origine à la fois une spécification et une implémentation) ont convergé pour former SAMLv2, et WS-Federation de Microsoft. Toutes utilisent intrinsèquement SAML.

Sécurisation des assertions

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 une partie différente du document XML.

-Le SP et L’IdP sont deux entités qui ont connaissance l’une 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.

Les cercles de confiance

La définition des relations de confiance entre les IdP et les SP à un plus haut niveau est cruciale. Un SP se repose sur les IdP pour assurer une authentification sûre de ses utilisateurs et la qualité de ses attributs. Réciproquement un IdP fait confiance aux SP quant à la bonne utilisation des attributs nominatifs. La formalisation de ces relations de confiance peut se faire de gré à gré entre chaque paire d’IdP/SP. Cependant, il est naturel de vouloir formaliser la définition de ces relations de confiance pour un ensemble de fournisseurs qui forment alors un cercle de confiance. L’inscription à un tel cercle impose de respecter des règles communes.

Au sein d’un cercle de confiance, des règles existent pour assurer la protection des données personnelles des utilisateurs qui peuvent être communiquées entre fournisseurs. SAML permet de communiquer des assertions d’authentification anonyme. Il existe aussi la possibilité d’utiliser un identifiant persistant et opaque spécifique à un trio IdP – SP – utilisateur. Ainsi un SP peut reconnaître un utilisateur d’une session à l’autre, sans le connaître nominativement.

Face aux solutions sophistiquées et complexes à déployer des fédérations d’entreprises, les éditeurs de SaaS adoptent des systèmes de fédération plus légers et plus adaptés au grand public comme OpenID, notamment les réseaux sociaux comme LinkedIn et Facebook, ces derniers étant des sources de renseignements pour les sites partenaires.

Vers un mix des technologies

Tout l’enjeu est maintenant de mettre en relation ces deux mondes, celui de l’entreprise et celui des SaaS grand public. Cette évolution peut s’appuyer sur les systèmes de SSO ouverts, modulaires et flexibles, pouvant supporter à la fois le SSO classique de l’entreprise, et l’ouverture vers l’extérieur au travers des systèmes de fédérations d’identités tels que SAMLv2 ou OpenID, en fournissant un point d’authentification fort et unique aux services et applications partenaires.

Claude-Jacques Tronquet, Developpeur IAM Bee Ware