Par Charles Dupont, Directeur général de USERCUBE
Le vocabulaire IT s’étoffe chaque jour de nouveaux noms et de nouveaux acronymes toujours prêts à déboussoler les non-initiés. Parmi cette pléiade d’appellations, certains concepts se répètent, d’autres se recoupent et certains sont même créés de toutes pièces par des cabinets soucieux de remettre au goût du jour des concepts désuets.
Malgré cette hémorragie verbale, il convient de conserver le sens de certaines nuances, et la distinction entre IAM et SSO (client ou web) en fait partie. Tout informaticien connaissant ses gammes sait que l’objectif d’un projet d’Identity and Access Management (IAM) est de créer un référentiel unique afin de gérer les accès et les droits des collaborateurs dans le système d’information. Une solution d’identifiant unique (SSO) permet, pour sa part, à un utilisateur d’accéder à plusieurs applications informatiques (ou sites web sécurisés) en ne procédant qu’à une seule authentification.
Référentiel unique, authentification unique, les problématiques sont a priori proches, et certains clients, influencés par les éditeurs toujours soucieux de faire gonfler la facture de licence, mais aussi par les cabinets de consulting toujours soucieux de vendre plus de complexité, sont tentés de mener les deux projets de front. L’argument massue, maintes fois répété et éculé, est que le SSO apporte un confort immédiat pour les utilisateurs et génère un ROI formidable permettant de justifier le projet IAM.
Alors que les technologies SSO existent depuis plus de quinze ans, leur faible taux de pénétration (hormis certains secteurs précis comme le monde hospitalier) et de nombreux échecs viennent malheureusement contredire cet argument.
Selon une pure stratégie de la sur-promesse (voir l’excellent livre « La stratégie de l’offre » de Henri de Bodinat), se contentant de dire oui à toutes les exigences du client et laissant les intégrateurs bâtir des usines à gaz, certains éditeurs proposent des boites à outils (tool kits) prétendant tout simplifier en répondant à la problématique SSO et à la problématique IAM.
En effet, un certain nombre d’éditeurs de solutions de SSO ont cherché à se différencier et à remonter la chaine de valeur en mettant à leur catalogue une offre IAM, d’autant plus que le marché du SSO est un marché fortement concurrentiel et en déclin, car la normalisation des applications vers des protocoles standards rend à terme ces solutions inutiles.
Or, c’est là que le bât blesse : utiliser un même produit pour ces deux problématiques rend les sociétés captives de leur éditeur ; de plus, cela complexifie et logiquement augmente le coût des deux projets.
IAM et SSO ne sont pas deux aspects d’un même problème, ils diffèrent catégoriquement de par leur nature et leur logique.
Les problématiques SSO sont des problématiques techniques et sécuritaires. L’architecture d’une solution SSO doit être construite avec l’objectif d’être la plus robuste possible face aux menaces sécuritaires et la plus résiliente possible (car il y a le risque de créer un Single Point of Failure). Sa mise en place dans l’entreprise est un projet qui concerne l’IT et qui peut être réalisé en quelques semaines. Un effort particulier doit être porté sur la robustesse, car un dysfonctionnement impacte directement l’utilisateur final qui ne peut plus se connecter aux applications.
L’IAM, à l’inverse, est une problématique organisationnelle, son architecture se doit d’être souple et capable de s’intégrer au système existant sans avoir l’ambition d’en devenir l’avant-garde sécuritaire. Les projets d’IAM sont à mener avec l’ensemble des services de l’entreprise (RH, IT, services généraux, services opérationnels) et prennent souvent plusieurs mois à être réalisés, étant donné les défis qu’ils représentent pour l’entreprise : définition des postes, des processus…
Ces outils en outre doivent être agiles afin de pouvoir s’adapter aux changements incessants de l’organisation.
En synthèse, les solutions de SSO sont des solutions techniques avec une portée tactique, aisément substituables, alors que les solutions d’IAM nécessitent une approche organisationnelle et ont une portée stratégique au niveau du système d’information.
Si ces deux outils sont complémentaires, les rassembler en un seul produit ou en un seul projet n’est en aucun cas une solution.
On comprend la contradiction qu’il y a à vouloir une architecture à la fois robuste et souple.
De même, mener ces projets de front est une erreur. En effet, on comprend la nécessité d’organiser la gestion des identités, de créer et mettre à jour les référentiels des habilitations avant de simplifier le login des utilisateurs via une solution de SSO.
En conclusion, le meilleur moyen, mais aussi le moins risqué, pour résoudre cette double problématique est d’opter pour deux solutions distinctes en ayant une stratégie de « best of breed » et en vérifiant que chaque solution est suffisamment moderne pour respecter les standards d’intégration garantissant une cohabitation harmonieuse de l’ensemble avec des cycles de vie des logiciels indépendants. Il convient également de réaliser les deux projets successivement : on commence par les fondations avec le projet IAM puis on propose éventuellement des fonctionnalités de SSO pour les applications qui ne supportent pas les protocoles standards.
