Définition de Single Sign On

Pourquoi mettre en oeuvre une procédure de Single Sign On au sein du réseau interne ? Quelles en sont les motivations, et surtout qu'est ce qu'une procédure Single Sign On ?

L'objectif du Single Sign On, noté SSO, est de centraliser l'authentification afin de permettre à l'utilisateur d'accéder à toutes les ressources (machines, systèmes, réseaux) auxquelles il est autorisé d'accéder, en s'étant identifié une seule fois sur le réseau. A terme, le SSO propage l'information d'authentification aux différents services du réseau, voire aux autres réseaux, et évite ainsi à l'utilisateur de multiples identifications par mot de passe.

Une entreprise, à l'heure actuelle, dispose généralement d'un ensemble de serveurs, tous ayant leur propre système d'authentification. Nous retrouvons ainsi par exemple un serveur sous Windows 2000, qui permet au postes client de se connecter au sein du réseau local, des serveurs web et bases de données sous i5/OS, des serveurs mail sous Linux, et des postes utilisateurs hétérogènes sous Windows et Linux.

Pour illustrer cela, prenons un exemple:

• L'utilisateur John, employé de l'entreprise, doit tous les matins s'identifier auprès du serveur d'authentification Windows 2000, afin d'avoir le droit d'accéder au réseau local;
• Par ailleurs, pour consulter son courrier électronique, il doit de nouveau entrer des identifiants de connexions;
• Enfin, pour accéder aux serveurs web ou aux bases de données, il doit s'authentifier plusieurs fois par jour.

Le SSO est un moyen qui permettrait à John de ne rentrer plus qu'une seule fois ses informations de connexion pour pouvoir avoir accès à tous les services du réseau. Généralement établit en début de journée, ce passe-droit serait valide pendant une durée limitée, typiquement jusqu'à la fin de la journée courante.

Toute la difficulté de l'exercice réside alors dans le niveau de confiance entre les entités d'une part, et la mise en place d'une procédure de propagation commune à toutes les entités à fédérer.

Une étude (RSA Security Survey Reveals Multiple Passwords Creating Security Risks and End User Frustration) menée en 2005 par RSA Security a montré qu'un utilisateur moyen dispose, en moyenne, d'une dizaine d'identifiants de connexion différents, où chacun de ces identifiants est spécifique à un service particulier. Gérer autant d'ID utilisateur et de mots de passe mène à une très grande frustration de la part des utilisateurs: 88% d'entre eux ressentent une profonde gêne à la manipulation d'autant de données sécurisées différentes. Il en ressort que la mémorisation d'autant de données n'est pas évidente, et que, pour la plupart des personnes interrogées, celles-ci finissent sur un post-it sur l'écran d'ordinateur. Comme nous pouvons nous en douter, la sécurité des systèmes d'information s'en retrouve profondément affaiblie.

L’existence des registres utilisateur multiples peut aussi affecter gravement les administrateurs et les fournisseurs d’applications. Les premiers doivent gérer les ID et mots de passe utilisateur résidant dans des registres utilisateur multiples. Pour couronner le tout, quand une personne quitte l’entreprise, toutes ses informations d'authentification dans les divers registres doivent être supprimées, une opération à haut risque pour le système de sécurité. Pour les fournisseurs d’applications dont les solutions doivent fonctionner dans un environnement hétérogène multi-niveaux, le moyen le plus économique de contourner le problème consiste souvent à créer une autre couche de registres utilisateur propres à l’application et de la sémantique de sécurité. Malheureusement, cela ne fait que repousser et renchérir le problème des registres utilisateur multiples pour les administrateurs et les utilisateurs des sites client.

[…] Notons que si une grande majorité des répondants semblent hésiter, la raison primordiale pourrait se situer dans les difficultés du travail en amont. Avant d'unifier les procédures d'accès aux différents systèmes, il paraît indispensable de mettre à plat l'ensemble des droits d'accès des utilisateurs aux différentes ressources de l'entreprise. En amont, 46% des répondants jugent indispensable d'effectuer un audit général du système d'information, devant 26% en faveur d'une étude sur les procédures de gestion des comptes utilisateurs, et 20% qui se contenteraient d'une étude sur l'attribution des droits. Ainsi, les difficultés techniques liées au déploiement sont citées en tête des freins au démarrage d'un projet SSO (34%), suivies par les implications organisationnelles (27%) et les coûts (14%) qui varient notamment en fonction des difficultés d'intégration. Enfin, à l'inverse des freins, le développement de la technologie des méta-annuaires, qui unifie l'accès aux différents annuaires de l'entreprise, sera pour 35% un facteur déterminant dans le processus de démocratisation du Single Sign On.

Extrait : Single Sign On : problématique comprise mais non prioritaire

Comme le montre l'extrait ci-dessus, il est intéressant de remarquer, en 2000, les difficultés pour les responsables informatique et sécurité de mettre en place une telle procédure. Bien évidemment, comme nous l'a montré le rapport de RSA Security, les raisons et les besoins ont grandement évolués ces dernières années, les techniques ont donc logiquement suivi le mouvement.

Il existe essentiellement quatre façons de mettre en place une telle procédure, certaines plus sûres, d'autres qui font illusion. Il faut donc bien choisir, et voir vraiment le pour et le contre pour chacunes d'entre elles. En effet, au final, le SSO met en avant un point de passage obligatoire pour avoir accès à toutes les ressources du système d'information.

Une manière de réaliser le Single Sign On est d'unifier tous les identifiants de connexion. Cette stratégie n'est qu'un leurre. Elle tend à fragiliser le système informatique, en rendant unique les identifiants de connexion pour toutes les ressources mis à disposition. Une fois que cet identifiant est connu, une personne malveillante à alors accès à toutes les ressources du système. Le vrai SSO permet au contraire de laisser le système d'information gérer cette pluralité de données de connexion, gardant ainsi une certaine stratégie de droits d'accès aux ressources.

Le SSO peut être réaliser aussi en regroupant en un endroit sécurisé toutes les données confidentielles d'un utilisateur relatives à son authentification vers les différentes ressources du réseau. Une telle procédure est généralement mise en place à l'aide de cartes à puce individuelles très protégées. Une carte à puce, propre à un utilisateur, détient alors l'ensemble des informations sensibles relative à cet utilisateur. Néanmoins, le point fort de cette architecture est aussi sa plus grande faiblesse. En effet, il suffit d'arriver à casser les protections de la carte à puce pour avoir accès à toutes les données sensibles, dont les noms d'utilisateurs avec leur mot de passe, et parfois même les droits d'accès.

La dernière méthode, peut-être la plus ingénieuse, et de laisser les différents ressources gérer les authentifications. Ainsi, les données sensibles ne sont plus garder en un unique endroits précis (comme une carte à puce) mais se retrouvent dispatchées sur tout le réseau. L'accès à un centre de données confidentielles fragilisent donc une partie du réseau, mais non son ensemble. Il devient alors plus facile de cibler les ressources critiques et mal protégées. Pour permettre l'intéraction entre ces différents centre d'informations, et pouvoir faire du SSO, il convient alors de mettre en place une structure centrale, sur laquelle les dît centres se regroupent. Cette structure centrale ne fait alors que mettre en relation les différents centres, comme un aiguilleurs. L'avantage certain est que si cette structure “tombe”, le système d'information reste, lui, protégé.

Nous pourrions souligner une derrière manière de mise en oeuvre le SSO: mettre en place un serveur d'authentification en frontal. Cependant, elle est relativement difficile à mettre en oeuvre, car le serveur devrait connaître tous les protocoles d'echanges de données utilisés par les applications tierces nécessitant une authentification sécurisée. Ce mécanisme est généralement mis en place au sein d'un système d'information ultra limité, avec très peu de ressources.

La mise en place d'une procédure de Single Sign On (SSO) au sein d'un réseau modifie considérablement la stratégie de sécurité même du réseau. Plusieurs raisons peuvent amener une entreprise à adopter le SSO. Parmi elles, l'apport ergonomique au niveau utilisateur. L'atout évident d'un service SSO est la simplification des procédures d'authentification pour l'utilisateur final. Là où autrefois il était amené à fournir une dizaine de fois par jour ses identifiants de connexion, l'objectif final du SSO permet maintenant de limiter l'échange de ces données confidentielles à une unique fois durant un temps limité. Nous pouvons alors nous demander si cet apport ergonomique ne nuit pas à la sécurité du réseau informatique.

Le SSO s'appuie avant tout sur une politique de sécurisation de l'authentification, sans pour autant émettre une quelconque hypothèse sur la sécurité même du réseau. De nombreux avantages en ressortent. Tout d'abord, le SSO ne se soucis pas du support réseau sur lequel il s'applique. Il fournit donc une couche supplémentaire assurant une sécurité de bon niveau au niveau de l'authentification, au sein d'un réseau dont il ne connaît pas la nature. Elle serait alors renforcée si le réseau en lui même était plus sûr, par du chiffrement par exemple. Ensuite, il permet de limiter la divulgation des données confidentielles d'authentification sur ce réseau. Cela réduit considérablement les attaques basées sur l'écoute des paquets réseau. Il faut bien voir que le SSO ne concerne que la partie authentification d'un système d'information. Au sein d'un réseau, les stratégies d'attributions de droits et de partages de ressources ne sont alors pas concernées. Le SSO permet donc, de plus, de laisser le système gérer les droits des utilisateurs.

Une politique SSO au sein d'un réseau de plusieurs ordinateurs change indubitablement les habitudes des utilisateurs du système d'information. Là où autrefois il n'était pas gênant de divulguer ses identifiants de connexion à un collègue de travail, pour une durée limité, aujourd'hui, il se trouve que cette pratique rend à fragiliser considérablement la sécurité du système. Dans un réseau ayant adopté une telle politique, les données d'authentification deviennent un élément fondamental du degré de sécurisation du système d'information. Permettant alors d'avoir un accès total aux ressources mis à disposition, il revient à l'utilisateur même de faire attention à ne plus divulguer de telles informations. Parce que l'utilisateur n'a plus qu'à retenir que quelques données de connexion, l'erreur humaine devrait alors diminuer (et les fameux post-it sur les écrans disparaître).

Il faut donc bien voir que la sécurité du système informatique est renforcée grâce à une prise de conscience de la part des utilisateurs envers la divulgation de leurs données confidentielles. Le SSO ne fait donc que mettre en avant cette prise de conscience: les données confidentielles sont confidentielles, et par conséquent personnelles.

Enfin, le SSO permet de fédérer l'authentification de tous les services au sein du système d'information. De nombreux logiciels assurent par leurs propres moyens les accès utilisateur. Il devient alors très compliquer de centraliser ces authentifications, et surtout d'appliquer des stratégies de sécurité particulière, comme les droits utilisateurs ou les accès à certaines ressources.