Avec un nombre croissant d'applications à leur disposition, et donc avec autant de mots de passe à mémoriser, les utilisateurs font de leur mieux : ils inscrivent ces codes secrets dans leur agenda papier, les notent sur des Post-it qu'ils collent autour de leur écran ou, plus simple, laissent leurs connexions ouvertes lorsqu'ils quittent leur poste de travail. Et ce, afin de ne pas avoir à répéter le rituel quotidien de l'accès sécurisé à leurs applications.

Pour juguler cette prolifération de mots de passe, un remède existe : le Single Sign-On (SSO). Il s'agit d'une gamme d'outils qui mémorise à la place des utilisateurs l'ensemble de leurs codes secrets et les présente automatiquement à chaque application qui en fait la demande. L'utilisateur n'a qu'à s'authentifier une seule fois, le plus souvent à l'ouverture de sa session de travail, le reste est pris en charge par le SSO. Les mots de passe peuvent être stockés de façon centralisée ou localement, sur une carte à puce, par exemple.

Mais aussi pratiques soient-ils, les SSO sont rarement déployés simplement pour faciliter la vie des utilisateurs. Ils s'intègrent généralement à un projet de sécurité plus large, dans lequel ils ne constituent qu'un élément secondaire, voire un simple bonus.

De fait, la plupart des projets de Single Sign-On prennent forme à l'occasion d'une refonte de l'architecture réseau. « Tout est parti de la PKI. Cela a permis de débloquer plusieurs projets qui étaient en attente faute de solution adéquate, dont la signature électronique et le SSO. Ce dernier était bien à l'étude auparavant, mais j'avais décidé de ne pas m'y lancer avant d'en avoir posé les briques, tels la PKI et le reverse proxy, car un SSO est beaucoup plus simple à déployer lorsqu'on dispose déjà d'un point d'accès unique au système d'information », explique Franck Moussé, RSSI de Dexia Sofaxis, un courtier d'assurances de Tours, spécialisé dans les collectivités locales.

Parfois, le SSO s'impose naturellement après une refonte du réseau, sans même avoir été réellement prévu à l'origine : « Nous avons constaté que notre annuaire LDAP et ses fonctions d'authentification par mot de passe étaient devenus un standard de fait au sein de l'université Paris V. Tous les mouvements de personnel [enseignants, étudiants, personnel administratif, NDLR] y sont répliqués, avec des profils d'utilisateurs très souples qui pouvaient facilement être étendus. Et parallèlement, nous avions créé un intranet partagé dont l'accès est contrôlé par un ensemble login-mot de passe, fondé sur l'annuaire. En fait, il s'agissait déjà d'une authentification unique. À partir de là, toutes les nouvelles applications bénéficiaient d'office de ce login-là, plus par opportunité que par planification d'un SSO ! » , reconnaît Patrick de Carné, DSI de l'université Paris V.

L'université a donc commencé à lier l'authentification de toute nouvelle application web à celle de son intranet, avant de décider finalement d'y fédérer toutes les autres applications Web propriétaires. Tout simplement parce que l'ossature d'un SSO était déjà présente : un annuaire centralisé des utilisateurs et un point d'accès unique au réseau.

Mais, il est aussi possible de déployer un SSO sans annuaire. Même si ce type de mise en oeuvre est encore plus simple et pourrait se justifier à lui seul, il s'intègre, là encore, dans des problématiques de sécurité plus vastes : « Le SSO est venu de la nécessité d'encourager les utilisateurs à fermer leur session de travail lorsqu'ils quittaient leur poste » , explique Daniel Bonniec, technicien réseau à la CCR (Caisse centrale de réassurance, une entreprise publique d'environ 250 personnes). « Puisque nous avions déjà une carte magnétique pour le contrôle d'accès physique et la gestion des horaires de travail, nous avons eu envie d'associer les deux. La même carte devait donc aussi servir à accéder aux postes de travail », poursuit le technicien.

Pas de SSO, donc, dans la définition initiale des besoins. Mais bien sûr, si la carte peut stocker le mot de passe Windows, elle peut aussi se charger des autres... et voilà donc le SSO qui joue l'invité surprise.

Lorsqu'il s'agit de fédérer l'accès à des applications Web, le SSO ne demande guère d'effort de mise en oeuvre, à tel point qu'il n'est pas exclu de le développer en interne. « Lorsque nous nous sommes rendu compte que nous avions déjà presque toutes les briques d'un SSO, il a suffi de développer en PHP une couche supplémentaire pour assurer la gestion des sessions entre chaque application dans un environnement web », se souvient Patrick de Carné.

Pour son SSO, l'université parisienne n'a ainsi eu qu'à créer un portail unique grâce auquel, une fois identifié sur son serveur LDAP, l'utilisateur découvre une page Web construite dynamiquement en fonction de son profil. Elle lui présente les liens vers les différentes applications auxquelles il a le droit d'accéder, et le portail se charge de propager l'authentification initiale. Outre l'annuaire central OpenLDAP, l'architecture est fondée sur des serveurs Linux et Windows 2003 Server et elle exploite aussi bien PHP et ASP que l'architecture.NET de Microsoft (compatible avec Linux grâce à l'infrastructure Mono). L'accès depuis l'extérieur de l'université est contrôlé par un reverse proxy libre mis en oeuvre par la société IdealX.

Et si le Single Sign-On de l'université Paris V ne gère pas encore les applications client-serveur, celui du centre hospitalier universitaire de Rouen, lui aussi développé en interne, s'en charge en revanche très bien. « Venant du monde des mainframes, où l'authentification unique est la norme, il était impensable de ne pas retrouver la même souplesse dans l'univers du client-serveur », affirme Jean-Michel Gobe, directeur adjoint, responsable du département architecture technique.

Aucun outil du commerce ne se révélant assez souple pour ses besoins de délégation de l'administration, le CHU a donc développé le sien. Là aussi, la partie visible du projet est un portail web servant de point d'entrée unique au système d'information. L'authentification y est collectée depuis une page de l'intranet (IIS), puis transmise à un serveur d'applications sous Unix chargé du contrôle d'accès en collaboration avec une base de données Oracle pour le stockage des mots de passe. Le serveur d'applications génère en retour une requête SQL contenant l'ensemble des droits (applications, accès, etc.) possédés par l'utilisateur. Le serveur Web s'en sert alors pour lui attribuer une page personnalisée lui donnant accès à l'ensemble de ses ressources.

Dans le cadre d'applications Web, il s'agit de simples liens, tandis que, pour les logiciels client-serveur, le portail génère des scripts de connexion pré-renseignés avec les mots de passe de l'utilisateur qui se chargent d'appeler les applications, via un client dédié lorsque c'est nécessaire (Telnet, etc.)

Pour l'entreprise ne désirant aucun développement, il existe une solution encore plus simple à mettre en oeuvre : la carte à puce. « Pour notre SSO, nous avions bien étudié la possibilité d'une authentification centralisée, mais cela nous paraissait trop complexe et posait des problèmes de compatibilité avec nos cartes magnétiques existantes. Nous avons donc choisi de faire ajouter une puce à nos cartes d'accès physique afin d'y stocker aussi les mots de passe de l'utilisateur », se souvient Daniel Bonniec, de la CCR.

Grâce à ce choix très pragmatique, la mise en oeuvre du SSO a été largement simplifiée : « Il a suffi une fois pour toutes d'identifier les fenêtres de demande de mot de passe de chaque application [une dizaine, NDLR], et de leur donner un nom unique. Ensuite, pour chaque utilisateur, il a fallu entrer dans la puce le nom de la fenêtre et le mot de passe associé. Cela se fait très simplement, à l'aide d'un utilitaire spécifique fourni par la solution que nous a livrée Prologue Software », poursuit Daniel Bonniec.

Après avoir recensé chaque événement de demande de mot de passe, la CCR disposait d'un SSO parfaitement opérationnel et, bien qu'il ne soit pas centralisé, entièrement déployé en trois mois auprès de ses 250 collaborateurs. Le tout, en s'offrant le luxe de conserver un double de chaque carte au service informatique, afin de remédier aux pertes de cartes.

S'il est difficile d'évaluer les moyens nécessaires au développement en interne d'un SSO, surtout lorsqu'il exploite de nombreuses briques déjà présentes, l'avis général est qu'il ne s'agit pas d'un travail très compliqué. « La mécanique d'un SSO en tant que telle n'est pas lourde : le nôtre a demandé deux à trois mois/homme en termes de développement », se souvient Patrick de Carné, de l'université Paris V.

Même constat au centre hospitalier universitaire de Rouen : « C'est un travail sur la durée, mais ce n'est pas un travail très lourd. Cela nous a pris du temps au démarrage pour organiser des groupes de travail, pour maquetter, valider et créer les interfaces utilisateur. Aujourd'hui, ce qui nous demande le plus de temps, c'est la création de nouveaux connecteurs avec la couche Single Sign-On lorsqu'une nouvelle application arrive. Et notre SSO occupe un analyste-développeur à mi-temps pour faire vivre le projet. Mais considérant qu'il s'agit du point d'entrée unique vers l'ensemble des applications de notre système d'information, ce n'est pas très lourd », précise Jean-Michel Gobe.

Chez Dexia Sofaxis, on estime que le projet a demandé environ 66 jours/ homme en l'état actuel (le SSO est utilisé pour administrer la PKI), et demandera 300 jours/ homme de développement pour s'étendre à toutes les applications métier.

Les ressources nécessaires se réduisent encore plus lorsqu'il s'agit de déployer un SSO qui n'est pas centralisé. « Il nous a fallu deux mois pour préparer le déploiement, et un mois pour passer tous les badges. Le plus long a été d'installer sur tous les postes de travail le lecteur de cartes à puce et le logiciel client. À raison de 30 minutes par poste [la formation de l'utilisateur est comprise, NDLR], cela a demandé trois mois pour deux personnes », se souvient Daniel Bonniec, de la Caisse centrale de réassurance.

« Le gain immédiat a été l'appropriation des applications par les utilisateurs. Notre personnel est, comme beaucoup, incapable de mémoriser plusieurs mots de passe ! Grâce à notre SSO, nos utilisateurs savent qu'on leur offre un bouquet de services pour un seul mot de passe à retenir », observe Patrick de Carné.

Mais le gain ne porte pas uniquement sur une plus grande simplicité d'utilisation des applications. Du point de vue de la sécurité, le fait de fédérer des applications autour d'une architecture Web unique permet de profiter d'une sécurité accrue grâce au chiffrement SSL. « Parce que nous étions sur des technologies Web, nous avons pu tout chiffrer en SSL. Cela est venu de façon très naturelle, car tout était déjà présent pour le faire. Et bien sûr, ce sont les connexions Wi-Fi qui en profitent le plus ! », poursuit Patrick de Carné.

Enfin, capter l'authentification de l'utilisateur avant l'application offre une grande souplesse. « Le SSO nous permet d'ajouter à la connexion des éléments de contexte, ce qui est une vraie valeur ajoutée par rapport à une connexion directe à l'application », conclut Jean-Michel Gobe.