| Directeur des Opérations,
Smile - Motoristes Internet |
| |
|
|
|
Il y a comme ça quelques technologies, la signature électronique par exemple, qui sont parfaitement au point, extrêmement utiles, et qui pourtant ont du mal à s'imposer. L'authentification unique, ou single sign-on, ou encore "SSO", est au nombre de ces technologies en mal d'amour : tout le monde les voudrait, tout le monde en perçoit bien les bénéfices, et pourtant tout le monde hésite aussi, imaginant un chantier considérable et semé d'embûches.
Les bénéfices, revenons-y. Combien de fois vous êtes-vous identifié aujourd'hui ? 2 ? 3 ? 5 ? Trop en tous cas. Et avez vous donné à chaque fois le même mot de passe ? Combien de mots de passe devez vous retenir ? Le confort des utilisateurs est évidemment l'un des premiers objectifs d'un SSO. Mais ce n'est pas le seul.
Il y a trois grandes raisons de mettre en place une solution SSO.
La première est le confort des utilisateurs et donc l'efficacité de leur travail.
| |
| "Combien de fois vous êtes-vous identifié aujourd'hui ? 2 ? 3 ? 5 ? Trop en tous cas"
|
| |
La seconde est la sécurité elle-même, et cela à plusieurs niveaux. D'abord au plan des process, parce qu'en facilitant la vie des utilisateurs, il est plus facile de leur demander une bonne gestion de leur mot de passe (les 'post-it sur l'écran.) .
Ensuite au plan du code, parce que si chaque application se construit son dispositif d'authentification, il y a un vrai risque que l'une d'entre elles présente une faille critique à ce niveau, les équipes de développement n'étant pas toutes expertes en sécurité.
Enfin, en termes d'administration de la sécurité, parce qu'une gestion centralisée est la seule manière d'assurer qu'un stagiaire qui quitte l'entreprise perd instantanément tous ses accès sur toutes les applications de l'entreprise.
La troisième motivation du SSO, souvent mésestimée, relève de l'infrastructure et de l'architecture logicielle. C'est le SSO qui permet de construire un portail composé de multiples briques indépendantes, en parfaite transparence pour l'utilisateur. Nous insistons sur cet aspect : au delà du confort, le SSO permet de nouvelles architectures car il lève les contraintes d'unicité du serveur ou même de l'environnement technique.
Souvenons-nous que c'est un des apports historiques du lien hypertexte : le caractère invisible des serveurs, entre lesquels l'utilisateur chemine d'un simple clic, sans percevoir la moindre frontière.
Or ce qui est vrai pour la navigation non-authentifiée ne le serait plus aussitôt que l'on est dans l'univers authentifié, c'est à dire pour la majorité des utilisations professionnelles en entreprise ?
| |
| "Le SSO permet de nouvelles architectures car il lève les contraintes d'unicité du serveur"
|
| |
On ne mesure pas bien l'immensité de cette régression : c'est tout simplement un principe fondateur du web que l'on a perdu au passage. Et qui reste à reconquérir par le moyen du SSO.
Faisons un rapide tour d'horizon de l'offre en solutions SSO. Dans le contexte d'applications web, il existe fondamentalement deux modes de SSO : géré côté client ou côté serveur.
Côté client, les seules solutions standards sont celles qui s'appuient sur les certificats X509 clients. Le certificat est "ouvert" par l'utilisateur en saisissant un mot de passe, puis adressé aux différentes applications qui le demandent.
L'authentificité du certificat, et donc l'identité de l'utilisateur sont établis, mais il reste à l'application à s'assurer de la non révocation et des droits actualisés pour cet identifiant. Le système n'est pas centralisé par construction, ce qui ne règle donc qu'une partie du problème.
Toutes les autres solutions "client", qui se proposent à l'aide d'un logiciel spécial, de mémoriser vos mots de passe pour les fournir de manière transparente aux applications qui le demandent -à la manière de ce que savent faire les navigateurs- relèvent du bricolage et ne sont satisfaisantes ni au plan de la sécurité, ni de la pérennité.
Côté serveur, la voie qui s'est imposée est celle de la délégation d'identification vers un système centralisé. La meilleure illustration, et la solution la plus complète, est la solution Open Source CAS. (Central Authentication System), initialement développée par l'université de Yale.
| |
| "Il n'y a plus d'excuses aujourd'hui pour remettre à demain le déploiement de l'identification unique"
|
| |
Chaque application, au lieu de présenter sa page de login, redirige l'utilisateur vers CAS pour son authentification. Le processus est donc totalement centralisé. CAS prend en charge le "login", et le contrôle auprès d'une base centralisée des utilisateurs et profils, qui est le plus souvent un annuaire LDAP.
CAS prend également en charge la gestion de sessions inter-applications, c'est à dire qu'une fois identifié par l'une des applications, l'utilisateur n'a plus à s'identifier auprès des autres applications interfacées à CAS. Outre son caractère Open Source, le principal atout de CAS est la disponibilité des modules d'interfaçage pour tous les environnements techniques : J2EE, PHP ou Dotnet, de sorte que la "cassification" d'une application est l'affaire de quelques jours à peine.
Avec la disponibilité de solutions solides, gratuites et multi-plateformes, il n'y a plus d'excuses aujourd'hui pour remettre à demain le déploiement de l'identification unique. Toute l'entreprise y gagnera, en termes de confort, d'efficacité, de sécurité et d'urbanisme. |
Patrice Bertrand |
