SSO - Single Sign On
Les techniques de SSO
Les composants
Dans un système d´authentification unique, on trouve en général les éléments suivants :
-
Le client qui est
un navigateur web. Il demande l´accès à l´application. -
Le
serveur d´authentification qui est l´élément central du système de SSO.
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.
-
Le
serveur d´application qui ne délivre les ressources qu´après s´être
assuré que le navigateur qui l´accède se soit authentifié auprès du serveur
d´authentification.
-
L´agent qui vérifie que l´utilisateur est authentifié.
- Eventuellement le portail web qui centralise l´accès aux applications autorisées (service d´authentification) et donne une vision globale à l´utilisateur de l´ensemble des applications auxquelles il a droit.
Fonctionnement d´un SSO
L´accès à une application dans un système SSO se fait en plusieurs temps :
- Inscription de l´utilisateur dans la base d´authentification (annuaire) stocké sur le serveur d´authentification
- Vérification par le serveur d´authentification que l´utilisateur a le droit d´accéder à l´application demandée
- Accès à l´application
Un jeu de va et vient a lieu entre le serveur d´authentification et l´utilisateur puis entre le serveur d´authentification et le serveur d´application pour vérifier les droits de l´utilisateur sur l´application à laquelle il a ou tente d´avoir accès.
Du coté de l´annuaire et de la gestion des droits
L´utilisateur doit être inscrit dans l´annuaire d´entreprise (souvent) pour être ensuite habilité à accéder aux diverses applications auxquelles il a droit.
La gestion des droits se fait ensuite via un outil du SSO qui va permettre de gérer les droits des utilisateurs stockés dans l´annuaire.
Du coté de l´utilisateur
L´utilisateur accède à la page d´authentification soit par accès volontaire via un portail d´accès aux applications soit par une redirection suite à une tentative d´accès à une application sans authentification préalable. Il s´identifie en saisissant son login et son mot de passe.
Ensuite, l´accès au serveur application se ferra depuis les liens du portail d´accès ou directement si l´utilisateur connaît le lien.
Du côté de l´application
Le serveur d´application est protégé par un " agent d´authentification " :
- L´agent intercepte chaque tentative d´accès à l´application et vérifie que l´utilisateur est authentifié (par exemple, la présence d´un cookie sur le poste de travail).
- Il s´assure ensuite auprès du serveur d´authentification que l´utilisateur est autorisé à accéder à la partie demandée de l´application.
Architectures d´un SSO
L´architecture mis en place par les logiciels de SSO utilise généralement le mécanisme d´une architecture n-tiers : l´application est utilisé sans transmission du mot de passe. En effet, le mot de passe n´est transmis par l´utilisateur qu´au serveur d´authentification lors de sa première connexion. Elle évite une propagation du mot de passe et des attributs de l´utilisateur entre l´agent d´authentification et le serveur d´authentification.
Attention seulement trois types d´architectures sont décrites dans cette partie, il en existe encore bien d´autre. Il faut aussi savoir qu´il n´existe pas d´architecture bonne ou pas bonne pour faire du SSO. Lorsque que ce service est mit en place les développeurs doivent se poser plusieurs questions comme le coût de développement (nombre de serveur etc.), le coût de maintenance, le temps de réponse etc.
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 (redirection HTTP). 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é (dans le cas présent le client c´est bien 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é
- 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.
Sécurisation d´un SSO
La mise en place d´un compte unique par utilisateur comporte des avantages notamment en terme de mutualisation des accès client à une application. Cependant, elle comporte également des risques.
En effet, le compte utilisateur étant unique, le vol de celui-ci entraîne un risque très important. La sécurisation de l´authentification devient donc primordiale.
La mise en place d´un SSO doit s´accompagner d´une mise en place de sécurisation du SI et notamment du réseau.
Quels moyens d´authentification utiliser
Plusieurs moyens vont permettre à un utilisateur de s´authentifier auprès de l´application à laquelle il veut avoir accès :
- le couple login/mot de passe est la méthode traditionnelle (il faut se méfier de son transport et de son utilisation)
- un certificat de type " client "
- un " ticket " qui sera soit rejouable ou non, soit limité ou illimité et qui permet de gérer la session ou l´authentification de l´utilisateur
Qu´est ce que le certificat ?
Le certificat de type " client " est stocké sur le poste de travail de l´utilisateur. Il permet d´identifier un utilisateur et de lui associer des droits. En général, il est transmis au serveur lors d´une connexion. Il affecte, alors des droits en fonction de l´accréditation de l´utilisateur. Il s´agit d´une véritable carte d´identité numérique. Le certificat contient le nom du destinataire, ainsi que sa clé publique et est validée ("signée") par un organisme reconnu, appelé Autorité de Certification (AC).
La valeur d´un certificat est proportionnelle à la confiance que l´on accorde à l´autorité qui a autorisé ce certificat. La signature de l´autorité de certification garantit que les informations du certificat comme la clé publique ou les informations transmises n´ont pas été modifiées. Pour effectuer cette vérification, il faut déchiffrer la signature avec la clé publique de l´AC du client.
Notion de ticket
La notion de ticket est attachée au protocole Kerberos. C´est un protocole d´authentification réseau créé au MIT qui utilise un système de tickets au lieu de mots de passe en texte clair. Ce principe renforce la sécurité du système et empêche que des personnes non autorisées interceptent les mots de passe des utilisateurs. Ces tickets ne transportent aucune information (relations de confiance). Ils reposent sur des clés privées.
Comment transporte-t-on les informations d´authentification ?
Il y a plusieurs moyens de transporter des informations d´authentification sous le protocole HTTP ou HTTPS. La communication s´effectue via les :
- Paramètres GET ou POST
- Cookies (identifiants échangés entre le client et le serveur)
- Certificat (vu précédemment)
Aucune garantie de confidentialité n´est assurée lors des accès à l´aide du protocole HTTP il est relativement simple à un pirate d´intercepter les requêtes d´un client et les réponses faites par le serveur. Par ailleurs, l´utilisateur n´a pas la certitude absolue d´être en cours de consultation du site qu´il croit. En effet, le protocole HTTP ne prévoit pas de connexion (on ne sait jamais vraiment avec qui on dialogue), ni de sécurité (tout le monde peut modifier n´importe quel paramètre dans une URL).
Tous les modes de transfert s´avèrent par contre sécurisé avec le protocole HTTPS qui utilise la notion de certificat.
Comment protéger complètement le SSO
Les différents serveurs doivent avant tout disposer de moyens de sécurité performant (firewall, anti trojan, anti virus etc…), étant donné que c´est eux qui stockent l´informations.
Ensuite voici la marche a suivre pour sécuriser sont réseau :
- le mot de passe de l´utilisateur ne circule qu´entre le navigateur client et le serveur d´authentification et nécessite nécessairement un canal crypté en HTTPS.
- Le serveur d´authentification envoie un cookie de session via un canal crypté en HTTPS. Les données stockées dans le cookie sont protégées (cryptage ou utilisation d´un ticket d´accès interprété par le serveur).
- Les ré-authentifications suivantes sont faites de manière transparente à l´utilisateur, sous réserve de l´acceptation d´un cookie privé et protégé. La portée de ce cookie est limitée au serveur d´authentification : c´est un cookie privé. Seul le serveur d´authentification peut lire et écrire ce cookie, qui ne contient qu´un identifiant de session. Le cookie est un moyen technique fiable qui va permettre à l´utilisateur d´être reconnu comme authentifié lors de son prochain accès au serveur. Il a une durée de vie limitée (quelques heures en général). Il est le moyen pour les navigateurs d´obtenir auprès du serveur d´authentification des tickets pour les clients sans avoir à se ré-authentifier.
L´usage d´un " reverse proxy " est conseillé. Il va masquer l´accès direct au serveur d´application. Il évite la nécessité d´avoir de l´HTTPS de bout en bout (pas de nécessité de HTTPS entre le " reverse proxy " et l´application) et diminue le nombre de requêtes (seules les requêtes autorisées accèdent au serveur d´application).
Mise en place d´un SSO
Même si la mise en place d´un SSO n´est pas facile à évaluer, elle va dépendre des exigences de sécurité qui y seront attachées : SSO centralisé ou non, avec ou sans annuaire LDAP, et surtout de l´ossature du réseau avant le projet.
Dans un premier temps, elle est considérée comme un travail peu compliqué (installation du serveur d´authentification). La complexité de mise en place arrive dans un second temps avec l´affiliation des nouvelles applications au SSO qui est un travail qui va s´étaler sur la durée. Elle nécessitera notamment des tests et la gestion des profils des utilisateurs par application.
Les étapes à suivre
- La première étape lors de la refonte du système de sécurité est la mise en place, si ce n´est pas déjà le cas, d´un annuaire centralisé des utilisateurs (LDAP).
- La deuxième étape est de dimensionner ce serveur, annuaire de l´entreprise, à un nombre accru de sollicitations. Le plus simple est de dupliquer l´annuaire sur d´autres serveurs pour alléger les accès serveur
- La troisième étape est la mise en place des logiciels SSO :
- L´agent d´authentification qui se situe sur le serveur d´application, l´application ou sur le reverse proxy. En fonction de l´architecture choisie.
- Un serveur d´authentification qui gère l´authentification des utilisateurs.
- Éventuellement le développement d´un portail web.
Comment intégrer une application à un système d´authentification SSO ?
L´intégration d´une application dans un système d´accès SSO comprend plusieurs phases qui sont :
- l´analyse de la façon dont l´authentification sera gérée par le SSO. L´architecture de celui-ci implique le développement ou non d´un agent à intégrer à l´application
- L´intégration de la nouvelle application sur un serveur de test.
- La mise en production de l´application.
- La gestion des habilitations des utilisateurs (informations stockés dans le LDAP).