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.