42
Principes de sécurité du système d’information
Première partie
Le Single Sign-On (SSO)
Le souhait légitime de tout utilisateur d’un système informatique est la simplicité d’utilisation. En de nombreux endroits il y a encore, pour identifier une seule et même personne
une multiplicité d’identifiants et de mots de passe, cela pourrait être :
• mon login de messagerie est jdupont ;
• mon login pour accéder à l’application de gestion des congés payés jdu, etc.
Certains organismes ont déjà fait des efforts pour faciliter la vie de leurs utilisateurs :
un seul et même login est utilisé pour la totalité des applications. Toutefois l’utilisateur
doit ressaisir celui-ci et le mot de passe associé chaque fois qu’il ouvre son application.
Il n’est pas rare de devoir saisir ces données plusieurs dizaines de fois en une journée de
travail. En plus de l’agacement lié à la saisie multiple de l’identifiant et du mot de passe
il y a des risques de sécurité réels :
• ces données sont probablement dupliquées dans les formats natifs de chacune des
applications ;
• puis-je faire confiance au format de stockage des mots de passe des applications ?
• la gestion du changement de mot de passe devient plus complexe.
Les objectifs des solutions dites de SSO sont donc multiples :
• avoir un référentiel centralisé des identités et des mots de passe, référentiel auquel
les applications s’adressent pour vérifier l’identité d’un utilisateur ;
• ne jamais divulguer le mot de passe (même sous une forme chiffrée) à une application, au pire l’application fournira au système de SSO les identifiants reçus
de l’utilisateur pour validation et au mieux un système de tickets (inspiré de
Kerberos) entre les trois acteurs que sont l’utilisateur (et son navigateur Web),
le serveur d’authentification du SSO et l’application, ce qui permet de ne jamais transmettre les éléments secrets (le mot de passe ou ce qui le remplace) à
l’application ;
• éviter les saisies multiples de l’identité pour accéder à plusieurs applications.
C’est ce dernier point qui est bien sûr le plus important aux yeux de l’utilisateur final, mais c’est aussi le plus difficile à mettre en œuvre. Si la prise en charge de tels
systèmes prend une certaine ampleur avec des applications « webisées », grâce à l’utilisation de HTTPS (HTTP (pour Hypertext Transport Protocol) est le protocole de
circulation des données sur le Web ; HTTPS en est la version sécurisée par chiffrement)
et de cookies (les cookies sont des éléments de données qui permettent de conserver
l’identification d’un utilisateur sur le Web pour une série de transactions), la mise en
œuvre d’un tel système dans le cadre d’autres applications dites « lourdes » est, elle,
plus complexe même impossible car elle ne permet pas d’utiliser les mêmes flux de
données entre l’utilisateur final, l’application et le serveur d’authentification. Le lecteur
désireux d’approfondir sa connaissance du fonctionnement, complexe, d’un système de
SSO pourra utilement lire deux présentations faites aux JRES 2003 par Olivier Salaün (Olivier Salaün. « Introduction aux architectures Web de Single-Sign On ». 2003.
Principes de sécurité du système d’information
Première partie
Le Single Sign-On (SSO)
Le souhait légitime de tout utilisateur d’un système informatique est la simplicité d’utilisation. En de nombreux endroits il y a encore, pour identifier une seule et même personne
une multiplicité d’identifiants et de mots de passe, cela pourrait être :
• mon login de messagerie est jdupont ;
• mon login pour accéder à l’application de gestion des congés payés jdu, etc.
Certains organismes ont déjà fait des efforts pour faciliter la vie de leurs utilisateurs :
un seul et même login est utilisé pour la totalité des applications. Toutefois l’utilisateur
doit ressaisir celui-ci et le mot de passe associé chaque fois qu’il ouvre son application.
Il n’est pas rare de devoir saisir ces données plusieurs dizaines de fois en une journée de
travail. En plus de l’agacement lié à la saisie multiple de l’identifiant et du mot de passe
il y a des risques de sécurité réels :
• ces données sont probablement dupliquées dans les formats natifs de chacune des
applications ;
• puis-je faire confiance au format de stockage des mots de passe des applications ?
• la gestion du changement de mot de passe devient plus complexe.
Les objectifs des solutions dites de SSO sont donc multiples :
• avoir un référentiel centralisé des identités et des mots de passe, référentiel auquel
les applications s’adressent pour vérifier l’identité d’un utilisateur ;
• ne jamais divulguer le mot de passe (même sous une forme chiffrée) à une application, au pire l’application fournira au système de SSO les identifiants reçus
de l’utilisateur pour validation et au mieux un système de tickets (inspiré de
Kerberos) entre les trois acteurs que sont l’utilisateur (et son navigateur Web),
le serveur d’authentification du SSO et l’application, ce qui permet de ne jamais transmettre les éléments secrets (le mot de passe ou ce qui le remplace) à
l’application ;
• éviter les saisies multiples de l’identité pour accéder à plusieurs applications.
C’est ce dernier point qui est bien sûr le plus important aux yeux de l’utilisateur final, mais c’est aussi le plus difficile à mettre en œuvre. Si la prise en charge de tels
systèmes prend une certaine ampleur avec des applications « webisées », grâce à l’utilisation de HTTPS (HTTP (pour Hypertext Transport Protocol) est le protocole de
circulation des données sur le Web ; HTTPS en est la version sécurisée par chiffrement)
et de cookies (les cookies sont des éléments de données qui permettent de conserver
l’identification d’un utilisateur sur le Web pour une série de transactions), la mise en
œuvre d’un tel système dans le cadre d’autres applications dites « lourdes » est, elle,
plus complexe même impossible car elle ne permet pas d’utiliser les mêmes flux de
données entre l’utilisateur final, l’application et le serveur d’authentification. Le lecteur
désireux d’approfondir sa connaissance du fonctionnement, complexe, d’un système de
SSO pourra utilement lire deux présentations faites aux JRES 2003 par Olivier Salaün (Olivier Salaün. « Introduction aux architectures Web de Single-Sign On ». 2003.