SSO et contrôle d’accès : quels rôles pour la sécurité du SI ?
Faut-il contraindre les solutions de SSO à contrôler l'accès des utilisateurs aux applications en fonction d'autres critères que leur simple authentification ?
Sur un projet de gestion d’identité, lors de la
configuration de la solution SSO, j’ai été confronté au besoin fonctionnel de
refuser l’accès aux applications, par le serveur de sécurité, des utilisateurs
qui ne remplissent pas certains critères techniques, bien qu’authentifiés.
Mon client considère, contrairement à moi, que ces critères
techniques qui correspondent fonctionnellement à une habilitation doivent être
pris en compte dans le processus d’accès aux applications, au même titre que
l’authentification.
Le rôle du SSO
SSO veut dire
« single sign-on » c'est-à-dire en français, authentification (ou
signature) unique. Ce qui est remarquable dans ce sigle est qu’il ne parle que
d’authentification et non de contrôle d’accès ou d’habilitation, ni même,
étonnamment soit-il, de sécurité, malgré ses deux « s ».
L’authentification unique implique donc que l’utilisateur
s’authentifie premièrement et une seule fois sur la solution de SSO. Ensuite,
pour qu’il n’ait plus à le refaire, le serveur de sécurité doit prendre à sa
charge la propagation de son identifiant vers toutes les applications
auxquelles l’utilisateur veut accéder.
Cela nécessite que le serveur de sécurité soit vu par les
applications comme étant un tiers de confiance qui leur apporte les éléments d’identification
dont ils ont besoin sur l’utilisateur qui a été authentifié. Cela veut dire que
le SSO ne doit pas autoriser les utilisateurs non authentifiés à accéder aux
applications. Il a donc un rôle de protection des applications.
Dans ce sens, nous pouvons affirmer que le SSO fait du contrôle d’accès premier niveau. Si l’utilisateur est authentifié (par le SSO) il peut accéder aux applications, s’il ne l’est pas, il ne peut pas.
Les deux fonctions principales d’une solution de SSO sont donc :
- du point de vue applicatif, de protéger les applications contre des utilisateurs non authentifiés et de leur fournir, à minima, l’identifiant de l’utilisateur qui désire accéder à leur contenu en leur assurant que cet utilisateur a été authentifié avec succès
- du point de vue utilisateur, d’authentifier les utilisateurs une seule fois et de ne plus leur redemander
Le rôle des éditeurs
Les éditeurs de logiciels ne font pas des outils qui implémentent
uniquement des normes ou des concepts, mais existent et persistent parce qu’ils
font avant tout du business. Cela veut dire qu’ils sont constamment à l’écoute
du marché et veulent être précurseur en matière d’innovation. Cela suppose que
leurs produits aient plus de fonctionnalités que celles proposées en standard
si on s’en tient au concept.
C’est comme cela que les normes naissent et évoluent ! Elles émanent d’un besoin qui se fait de plus en plus récurrent mais se bâtissent en se concentrant sur l’essentiel, le cœur du sujet et non sur les à-côtés, les plus qui distinguent une solution d’une autre. Ainsi les normes, dans leur version aboutie, traitent du sujet dans sa globalité, mais uniquement de ce sujet.
La norme du SSO
Le SSO n’a pas vraiment de norme, si on le restreint à sa
fonction d’authentification unique au sein d’une même entreprise. En revanche,
si on le considère de manière plus globale, à l’échelle du Web, alors le SAML
en version 2, est aujourd’hui la norme identifiée et aboutie de fédération
d’identité.
Il faut savoir qu’un outil de fédération d’identité est tout
à fait applicable en entreprise et devient alors un outil de SSO. C’est
d’ailleurs une fonctionnalité essentielle de tous les outils dits de SSO du
marché, ils ont la capacité à faire de la fédération d’identité en se basant
sur SAML.
Conclusion
Mes arguments face à mon client sont tout à fait légitimes,
puisque d’un point de vue conceptuel, j’ai raison. En revanche, il aurait aimé
avoir une solution qui fasse aussi du contrôle d’accès sur plus qu’une simple authentification
réussie des utilisateurs, même si elle était par certificat numérique. Mais au
stade de l’avancée du projet, le choix de la solution ne pouvait plus être rediscuté.
La solution choisie est bonne et la problématique n’est pas
insoluble : le SSO assure le maintien de la session de l’utilisateur et la
propagation des informations d’identité les concernant et les applications,
quand à elles, gardent leur capacité à accepter ou refuser les utilisateurs en
fonction des éléments que le tiers de sécurité leur fournit.