Architecture d'un SSO
Il existe plusieurs type d'architecture de SSO.
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 (maintient de la session d'authentification) et aux applications (transmission de l' identité de l'utilisateur).
L'application ne recueille jamais les éléments d'authentification de l'utilisateur (couple identifiant + mot de passe).
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.
Utilisation d'une architecture classique
Le schéma suivant présente les divers messages qu´il existe entre les composants d´un SSO simple.
•1. Demande d´accès à une application sans authentification préalable.
•2. L´agent intercepte la requête.
•3. L´agent demande au serveur d´authentification si celui-ci est authentifié. Le serveur d´authentification lui dit que non. L´agent bloque la requête.
•4. Pour cela, un formulaire d´authentification est envoyé au poste client par le serveur d´authentification.
•5. L´utilisateur fournit son login et son mot de passe au serveur d´authentification en retour.
•6. La phase d´authentification nécessite la vérification du mot de passe auprès de la base de référence. La plupart des systèmes de SSO implémentent plusieurs modes d´authentification mot de passe, certificat etc. Le serveur d´authentification peut être ainsi connecté à plusieurs bases (annuaire LDAP, base de données, etc.).
•7. Le serveur d´authentification renvoie un jeton de session (cookie) au client.
•8. Une fois l´utilisateur authentifié, la session de l´utilisateur est maintenue sur son poste client par le cookie. La transmission de l´identité de l´utilisateur à l´application passe forcément par le poste client. Le navigateur de l´utilisateur est redirigé vers l´application, muni des éléments d´identification. Les données de sécurité sont insérées dans les entêtes HTTP. L´agent intercepte la requête, il vérifie bien que le client est authentifié, il donne donc l´accès a l´application. Une fois authentifié pour une application, une session applicative classique est mise en place.
•9. affichage de l´application.
Utilisation d´un portail Web
En général, la mise en place d´une solution SSO passe par la mise en place d´un portail où va se localiser le service d´authentification de l´ensemble des applications. Le portail devient le seul point d´accès aux applications. Il affiche l´ensemble des applications sous forme de lien auxquelles l´utilisateur a droit. Toutes les applications (applications autonomes ou non) délèguent au portail le travail d´authentification des utilisateurs
Le schéma suivant présente les divers messages qu´il existe entre les composants d´un SSO utilisant un portail web.
•1. Connexion au serveur web avec le login / mot de passe.
•2. Le serveur web demande l´authentification du client au serveur d´authentification.
•3. le client authentifié, reçoit le cookie de session, ainsi que la page html lui listant toutes les applications auquel il a accès.
•4. L´utilisateur clique sur une application visible dans la page web retourné par le serveur web.
•5. L´agent intercepte la requête, demande une authentification du client au serveur d´authentification, celui-ci lui répond oui. L´agent laisse donc passer la requête au serveur d´application.
•6. le serveur d´application retourne l´application au client.
Architecture avec Reverse Proxy (boîte à mots de passe)
Le " reverse proxy " est un ensemble de serveurs d´infrastructure mis à la disposition des applications pour contrôler leurs accès. Dans ce mode de fonctionnement, il n´est plus nécessaire de déployer les agents d´authentification sur les serveurs d´application, ce sont les agents des " reverse proxy " qui vont contrôler les règles de sécurité applicables.
Un " reverse proxy " remplit le double rôle d´authentification de l´utilisateur et de login de l´utilisateur auprès de chaque application. Il peut ainsi gérer l´authentification de plusieurs applications.
Voici un exemple avec un client déjà authentifié
•1. Chaque demande de connexion à une application est redirigé vers le reverse proxy, le client.
•2. L´agent du reverse proxy intercepte les accès utilisateur
•3. L´agent vérifie l´authentification de l´utilisateur via le serveur d´authentification. Il se trouve que le client est authentifié
•4. Le reverse proxy demande au serveur d´application, l´application réclamé par le client.
•5. le reverse proxy retourne l´application au client.
Cette architecture épargne le travail de modification des applications web existantes tout en évitant le travail déploiement sur les postes client. En effet, il peut se révéler coûteux ou difficile de modifier les applications pour y intégrer un agent d´authentification. On peut envisager une solution de type " reverse proxy " où on installe un agent d´authentification en frontal d´un ensemble d´applications.
