Techniquement, le projet de SSO ne pose pas de problème majeur si l’inventaire applicatif de l’entreprise a été correctement effectué au départ. En revanche, il a un impact colossal sur la structure organisationnelle de la société. Un aspect à ne pas ignorer.
Menée en juin 2000 auprès de directeurs informatiques et de responsables de sécurité français, une enquête d’Arthur Andersen faisait état de la complexité d’un projet de SSO. Pour 49 % des personnes interrogées, le SSO ne constituait pas alors une priorité, chiffre indubitablement lié aux difficultés de mise en ?”uvre constatées par ces responsables informatiques.Pour près de 46 % d’entre eux, tout projet de SSO doit en effet être précédé d’un audit général du système d’information ; 26 % estiment qu’il faut également analyser les procédures de gestion des comptes des utilisateurs et 20 % pensent qu’aucun projet ne peut débuter sans des travaux préalables d’étude des procédures d’attribution des droits.Un énorme travail se situe donc en amont, au niveau de la phase d’audit et d’organisation.
Faire un état des lieux et prévoir les difficultés organisationnelles
Ces difficultés organisationnelles correspondent à la réalité qui, en deux ans, n’a pas changé. “Un projet de SSO est très structurant pour l’entreprise, explique Valère Pascolo, Business Development Manager de Computer Associates. Il ne s’agit pas d’installer un simple boîtier. Le projet n’est pas neutre pour l’organisation de la société, qui doit effectuer un état des lieux avant de mettre en place une démarche structurée.”“Cette phase organisationnelle est d’autant plus complexe que le SSO constitue un projet transversal, souligne Frédéric Preto, directeur technique de Linkware. Il implique un grand nombre d’applications au travers de différents services qui ne sont pas habitués à travailler ensemble.”Peu d’entreprises possèdent en effet un référentiel centralisé pour gérer les autorisations des utilisateurs. Elles sont encore plus rares à disposer de procédures écrites pour statuer sur la ou les personnes autorisées à créer et à administrer des comptes utilisateurs.Souvent gérée de manière empirique, par service ou par responsable d’application, cette structuration des autorisations ne va pas sans engendrer des problèmes politiques, comme le souligne Yann Morvan, responsable avant-vente chez iPlanet.“C’est notamment vrai pour les grandes sociétés dotées de filiales dont les responsables gèrent les utilisateurs. Ils perçoivent la mise en ?”uvre du SSO comme une perte de pouvoir.” D’autant plus, ajoute Laurent Charveriat, directeur associé de CyberNetworks, “que l’indispensable phase d’audit risque de faire apparaître des dysfonctionnements imputables forcément à quelqu’un, ou des impossibilités techniques “.“Le marché évolue et les entreprises mènent leurs réflexions de façon plus intelligente, précise toutefois Cyril Dujardin de Certplus. Elles n’arrivent plus en désirant mettre en place un projet de SSO ou PKI, mais en quête d’une solution au problème qui se pose. En d’autres termes, elles ont une vision plus “solution” et moins “technique” des choses.” Cette évolution favorise des approches plus modulaires.Plutôt que de tout chambouler pour mettre en place du SSO, les entreprises procèdent par étapes en adoptant l’authentification unique par groupe d’applications et d’utilisateurs. Cela n’empêche pas la phase d’audit de leur système ; en effet, le choix d’un outil doit s’adapter à l’existant de l’entreprise, même si certaines applications ne seront prises en compte que plus tard.
Simplifier sans introduire de nouvelles failles
Outre la dimension purement humaine et le déploiement d’un référentiel pour centraliser les droits des utilisateurs, l’audit doit également comporter une phase technique d’identification des chaînes métier, de façon à localiser les procédures d’authentification existantes. Alors seulement l’entreprise positionne les nouvelles procédures entre les applications, le moteur de SSO et les utilisateurs.“Il n’existe pas une bonne solution type d’architecture SSO, mais seulement des compromis, explique Frédéric Preto de Linkware. Il convient de bâtir des scénarios, puis de les tester en vérifiant, au passage, qu’une simplification du processus d’authentification n’introduit pas de nouvelles failles de sécurité dans le système.”Un serveur de SSO ne se contente pas, en effet, de servir d’intermédiaire entre l’utilisateur et une application. Pour certains processus complexes, il peut être amené à s’authentifier auprès d’une application pour le compte d’une autre. Il faut donc également définir des droits pour les applications (quelle application ou composant a le droit de discuter avec quelle application ou composant), sans pour autant ouvrir de nouveaux ports, au niveau du coupe-feu par exemple, susceptibles d’être exploités par un pirate.
