Depuis longtemps, tant la multiplicité des comptes utilisateurs que la nécessité de ressaisir un compte et un mot de passe pour chaque application informatique, ont posé problème aux gestionnaires des systèmes d’information.
Taper son login et son mot de passe 10 ou 20 fois par jour est inutile et lassant. Mais surtout gérer de multiples sources d’authentification est générateur de failles de sécurité surtout quand on sait que les utilisateurs vont à coup sûr réutiliser le même mot de passe. Si une source est compromise, tout le système s’écroule.
Les annuaires
Les annuaires d’authentification ont ainsi fait leur apparition. Ils ont pour vocation de gérer les comptes utilisateurs, leur authentification et d’offrir un processus de validation des comptes, première brique d’un vrai SSO.
Tous les éléments sont en place pour offrir aux applications, et surtout aux utilisateurs, un vrai système SSO. Mais comment cela fonctionne t’il réellement en pratique ?
Le principe du SSO
Le principe général est toujours le même, c’est un couple à trois : le client, le serveur applicatif demandeur de l’authentification et l’autorité.
Comme le client s’est déjà authentifié auprès de l’autorité ( le Single Sign On ! ), le serveur applicatif lui demande un justificatif d’identité. Si le client accorde sa confiance au serveur applicatif, il lui fournit les éléments et celui les fait valider par l’autorité.
L’identité est donc validée par le serveur applicatif de la même manière que si l’utilisateur avait saisi son mot de passe mais sans que celui ci ait transité par le serveur applicatif.
SSO en Intranet, La mécanique est relativement simple :
L’utilisateur s’est connecté, probablement au travers d’Active Directory ou éventuellement d’un annuaire LDAP. Il dispose donc de pièces d’identité que toute application pourra soumettre ou tout serveur Web demander et vérifier. Ce qui rend le fonctionnement simple, c’est que sur un Intranet le client accorde par défaut sa confiance à l’application. Tout est donc transparent pour l’utilisateur.
SSO sur internet, le principe se complique un peu :
Rien ne prouve que l’application soit légitime pour demander une identité, il est donc nécessaire de demander un accord au client, ce qui peut se faire sous plusieurs formes :
– Diriger l’utilisateur vers une page de l’autorité qui demande l’accord de l’utilisateur : il s’agit simplement de cet écran que vous connaissez tous, « Se connecter avec … » ou la possibilité de se connecter avec Facebook, Google, Linkedin, etc. L’utilisateur va alors soit saisir son identité, mais sans que l’application ne reçoive de mot de passe, pour la première connexion, et pour les demandes suivantes. La même page, une fois la connexion faite, permettra à l’utilisateur, d’un simple clic, d’accorder l’accès à l’application. Notez toutefois que l’application va recevoir des éléments vous concernant, à minima votre login, mais aussi d’autres informations détenues par l’autorité.
– Demander l’identité complète de l’utilisateur : compte et mot de passe et les soumettre à l’autorité. Attention à cette méthode car elle présente plusieurs failles de sécurité : d’abord, assurez vous que le protocole SSL est utilisé, sinon vos mots de passe et login transiteront non chiffrés sur le réseau, entre vous et l’application puis entre l’application et l’autorité, et surtout l’application va disposer des informations en clair. De toute façon, rien ne l’empêche de les conserver …
Olivier Piochaud, Président Directeur Général d’Apsynet
