Single Sign-On

Certains logiciels de SSO assurent également la fermeture de toutes les sessions applicatives de l’utilisateur lorsqu’il se déconnecte.

Certains logiciels de SSO assurent également la fermeture de toutes les sessions applicatives de l’utilisateur lorsqu’il se déconnecte.

2-Amélioration de la sécurité

L’accès nomade par le web à des applications nécessite de sécuriser la phase d’authentification sans faire d’hypothèse sur la sécurité du réseau qui relie clients et serveurs. L’architecture de type SSO, en concentrant cet effort de sécurisation sur le (ou les) serveur(s) d’authentification, permet de mettre en œuvre sur ce point une politique de sécurité cohérente tout en allégeant l’effort d’écriture des applications. L’utilisation d’un service commun d’authentification devrait également faciliter l’évolution des méthodes d’authentification ou la prise en compte de plusieurs niveaux d’authentification en fonction de la sensibilité des applications accédées.

La mise en place d’un SSO est en outre l’occasion de donner de bonnes habitudes aux utilisateurs : ils ne doivent délivrer leur mot de passe qu’au seul serveur d’authentification dont la bannière de login et l’URL (utilisation d’un certificat serveur recommandée) sont bien identifiés.

3-Rationalisation des applications et de la gestion des comptes

D’une manière générale, les applications web souffrent de leur manque d’intégration avec le système d’information. Les services sont rendus par une multitude de CGI sans relation les uns avec les autres et pour lesquels on a chaque fois redéveloppé la gestion de l’authentification. L’utilisation d’un service commun d’authentification doit permettre le développement plus rapide d’applications offrant toutes les mêmes garanties de sécurité

Avec son système d’authentification propre chaque application assure sa propre gestion des comptes utilisateurs. Cela implique la mise en place d’une politique cohérente de gestion des comptes.

Architectures classique d’un SSO web

L’architecture de la plupart des produits de SSO est inspirée de Kerberos; ils utilisent largement sa terminologie et partagent ses concepts de base qui sont les suivants :

* Les applications sont déchargées du travail d’authentification des utilisateurs. Cette tâche est assurée par un serveur d’authentification dédié.

* Le serveur d’authentification délivre des tickets au client (maintien de la session d’authentification) et aux applications (transmission de l’identité de l’utilisateur). Ce second ticket transite également par le client.

* L’application ne recueille jamais les éléments d’authentification de l’utilisateur (couple identifiant + mot de passe par exemple).

* Il existe une relation de confiance entre les applications et le serveur d’authentification. A noter que Kerberos n’utilise que des techniques de cryptographie symétriques ; l’utilisation de certificats X509 (utilisant des algorithmes asymétriques) peut permettre de simplifier l’architecture du système.

Le serveur d’authentification

Le serveur d’authentification est l’élément central du système de SSO puisqu’il assure l’authentification de l’utilisateur, la persistance de sa connexion et la propagation de l’identité de l’utilisateur auprès des applications. L’utilisateur fournit ses éléments d’authentification au serveur d’authentification.

Si le mode d’authentification est le mot de passe, la phase d’authentification implique la vérification du mot passe de l’utilisateur auprès d’une base de référence.

Et si le serveur implémente l’authentification par certificats sa tâche consistera à vérifier la validité du certificat, la chaîne de certification et les listes de révocation.

Lorsque l’utilisateur a été authentifié, le serveur d’authentification maintiendra la session de l’utilisateur en positionnant un cookie HTTP sur le poste de l’utilisateur. Les données stockées dans le cookie sont protégées (cryptage ou utilisation d’un ticket interprété par le serveur) et sa portée est idéalement limitée au serveur d’authentification. Le cookie HTTP est le seul moyen technique fiable à notre disposition pour que l’utilisateur soit reconnu comme authentifié lors de son prochain accès au serveur.

Si l’utilisateur a été orienté vers le serveur d’authentification par une application cible, le serveur doit, en retour, fournir l’identité de l’utilisateur à l’application.

Par identité on entend soit uniquement un identifiant, un email et/ou un ensemble d’attributs de l’utilisateur. La transmission de l’identité de l’utilisateur à l’application transitera forcément par le poste de l’utilisateur. Soit le serveur d’authentification utilise une redirection HTTP, soit il renvoie à l’utilisateur un document HTML incluant un programme Javascript de redirection. Dans tous les cas le navigateur de l’utilisateur est redirigé vers l’application, muni des éléments d’identification. L’application ne fait appel qu’une fois au serveur d’authentification et gère ensuite une session applicative classique avec l’utilisateur.

En conclusion le serveur d’authentification est l’élément central du SSO :

* Authentification utilisateur + maintient session

* Propagation identité vers applications

L’agent d’authentification :

„ L’agent vérifie que l’utilisateur est authentifié ; s’il ne l’est pas, il le redirige vers le serveur d’authentification. Si le client s’est déjà authentifié auprès du serveur d’authentification (attesté par la présence d’un cookie) le serveur le redirige directement vers l’agent d’authentification