Le système d'information s'ouvre à la fédération d'identité

Alors que les projets de gestion des accès et des identités ont la cote en entreprise (lire l'article "PCA et gestion des accès : priorités des RSSI en 2006" du 27/06/2007), la mobilité et les interconnexions entre industriels engendrent une nouvelle problématique de sécurité : l'authentification d'invités de confiance sur le réseau. Pour y répondre, des projets de fédération d'identité sont nés.

La fédération d'identité tient finalement en deux éléments. Le premier, la délégation de l'authentification, consiste à authentifier l'utilisateur depuis le service d'authentification interne, et non pas depuis celui du fournisseur de l'application. Le deuxième élément, la propagation des attributs utilisateurs, va permettre de propager depuis l'entreprise utilisatrice un numéro unique reconnu et des attributs de comptes internes afin de communiquer.

"La première chose à faire dans un projet de fédération d'identité est de se mettre d'accord sur les méthodes d'authentification. Est-ce un mot de passe de connexion, une communication SSL avec certificat, une authentification forte ? Parce qu'une fois ce choix fait, il ne faudra plus y revenir. Ensuite, l'entreprise doit s'assurer de l'authentification mutuelle des passerelles que l'on va mettre en place", note Bernard Montel, directeur technique de RSA Security pour la France et Israël.

Le partage d'identité entre deux entités distinctes est permis par le protocole standardisé et sécurisé SAML 2.0, soutenu par la Liberty Alliance. Outre SAML, il existe aussi des spécifications telles que WS-Security et WS-Federation, soutenues par le consortium WS-I (Web Services interoperability). Enfin, le projet Shibboleth, développé depuis 2001, se présente comme une extension de SAML enrichie. Toutes ces normes fonctionnent autour du standard LDAP pour assurer le dialogue entre les différents annuaires.

"Dans le cas d'une authentification mutuelle de passerelles, vous n'êtes pas certain que la personne qui se connecte soit la bonne. Pour certains systèmes sensibles, il est intéressant d'ajouter à la fédération d'identité une authentification forte. Il est ensuite possible d'aller plus loin en matière de sécurité, en signant par exemple tous les échanges réalisés durant la fédération. Ainsi, avec une enveloppe SAML, l'administrateur sera capable de faire de l'audit et de la tracabilité sur les opérations effectuées", déclare Bernard Montel.

L'authentification forte est gérée aussi en interne par le système d'authentification de l'utilisateur, puis véhiculée par le biais de SAML sous la forme d'un niveau d'authentification. Ce niveau pourra être utilisé pour mesurer le degré de confiance de l'utilisateur. Pour que cette sécurité fonctionne de façon optimale, la clé du projet porte donc sur le partage d'informations et la définition de règles communes.

"Dans un token, vous pouvez fédérer tous les éléments de connexion via des outils de SSO. Sur la carte seront stockés le certificat, le login mot de passe, la clé de chiffrement... tout ce qui peut être considéré comme un élément secret. Le client VPN IPSec va ensuite communiquer directement avec les applications distantes et pousser un code PIN unique. C'est ce code PIN qui remplace tous les identifiants de l'utilisateur", affirme Julien Champagne, directeur de la division entreprise d'Aladdin Knowledge Systems.

La première partie du projet est donc la plus importante : définition des profils utilisateurs, définition de qui se charge de la fédération d'identité, et par quels moyens techniques. La mise en œuvre, elle, est désormais bien maîtrisée par les spécialistes de la gestion d'identités (BMC, CA, IBM, Novell...). C'est aussi dans cette phase projet qu'il convient de s'adapter aux usages.

Plusieurs raisons peuvent en effet conduire à un projet de fédération des identités. Sur Internet, les services communs et les partenariats entre sites Web peuvent par exemple aboutir à ce type de projet. L'enjeu est alors de garantir à l'utilisateur la confidentialité de ses données personnelles tout en lui proposant des produits associés.

En entreprise, la fédération d'identité va être également employée pour remplacer des extranets clients / fournisseurs par un site Web commun où les utilisateurs iront s'authentifier. De même pour les intranets au sein d'un groupe dispersé géographiquement. C'est enfin un moyen d'ouvrir une ressource locale à d'autres utilisateurs.

Contrairement à d'autres solutions, la fédération d'identité intègre totalement les invités de confiance dans le système d'authentification, avec pour avantage de gérer la durée de vie de l'identité en cas de départ, d'arrivée ou de modifications des droits d'un utilisateur, là où un compte créé à part est souvent ouvert à vie. Autre avantage, l'utilisateur accède à une information structurée, véhiculée par la passerelle, mais sans avoir jamais accès au système d'information du fournisseur.

Si la formalisation de sa gestion des identités et des accès est un préalable nécessaire à tout projet de fédération d'identités, la mise en place d'une solution d'authentification unique - ou SSO - n'est en revanche pas obligatoire pour commencer à travailler. D'ailleurs, SSO et fédération d'identités se complètent idéalement. Il devient ainsi possible d'étendre l'authentification unique aux utilisateurs nomades ou ponctuels.

"Il faut en tout cas compter un délai de 3 à 9 mois pour un projet de fédération d'identité standard. Il y a toujours un délai incompressible dû au fait que le projet réuni deux entités différentes qui doivent dialoguer entre elles pour avancer. L'aspect organisationnel est le plus long, la partie technique est au contraire la plus rapide", complète le directeur technique de RSA Security.