SSO

L'authentification unique (ou identification unique ; en anglais Single Sign-On ou SSO) est une méthode permettant à un utilisateur de ne procéder qu'à une seule authentification pour accéder à plusieurs applications informatiques (ou sites internet sécurisés).

Sommaire 1 Objectifs 2 Avantages 3 Critiques 4 Architecture 4.1 Approche centralisée 4.2 Approche fédérative 4.3 Approche coopérative 5 Normes et outils pour l'authentification unique 5.1 Serveur d'authentification/identification 5.2 Délégation d'authentification 5.3 Stockage 5.4 Format de données et d'échange 5.5 Proxy 5.6 Le service compatible 5.7 Protocoles 6 Références 7 Voir aussi 7.1 Articles connexes 7.2 Liens externes

Objectifs

Les objectifs sont multiples :

• simplifier pour l'utilisateur la gestion de ses mots de passe : plus l'utilisateur doit gérer de mots de passe, plus il aura tendance à utiliser des mots de passe similaires ou simples à mémoriser, abaissant par la même occasion le niveau de sécurité que ces mots de passe offrent ;
• simplifier la gestion des données personnelles détenues par les différents services en ligne, en les coordonnant par des mécanismes de type méta-annuaire ;
• simplifier la définition et la mise en œuvre de politiques de sécurité.

Il existe trois grandes classes d'approches pour la mise en œuvre de systèmes d'authentification unique : les approches centralisées, les approches fédératives et les approches coopératives.

Avantages

Les avantages de l'authentification unique incluent :

• La réduction de la fatigue de mot de passe : manque de souplesse liée à l'utilisation de différentes combinaisons de nom d'utilisateur et de mot de passe ^[1]
• La réduction du temps passé à saisir le même mot de passe pour le même compte
• La réduction du temps passé en support informatique pour des oublis de mots de passe ^[2]
• La centralisation des systèmes d'authentification
• La sécurisation à tous les niveaux d'entrée/de sortie/d'accès aux systèmes sans sollicitation multiple des utilisateurs
• La centralisation des informations de contrôles d'accès pour les tests de conformités aux différentes normes

Les technologies fournissant SSO utilisent des serveurs centralisés d'authentification que toutes les autres applications et systèmes utilisent pour l'authentification, combinant ceci avec des techniques logicielles pour s'assurer que les utilisateurs n'aient pas à entrer leurs identifiants plus d'une fois.

Critiques

Comme SSO donne accès à de nombreuses ressources une fois l'utilisateur authentifié (il a les "clés du château"), les pertes peuvent être lourdes si une personne mal intentionnée a accès à des informations d'identification des utilisateurs. Avec SSO, une attention particulière doit donc être prêtée à ces informations, et des méthodes d'authentification forte devraient idéalement être combinées (par exemple, l'usage d'une carte à puce) ^[3]

Architecture

Approche centralisée

Le principe de base est ici de disposer d'une base de données globale et centralisée de tous les utilisateurs ou d'un annuaire. Cela permet également de centraliser la gestion de la politique de sécurité. Un exemple de mise en œuvre est le logiciel libre LemonLDAP, un autre exemple est le logiciel libre Vulture.

Cette approche est principalement destinée à des services dépendant tous d'une même entité, par exemple à l'intérieur d'une société au sein de leur gestion des Middleware.

Approche fédérative

Dans cette approche, dont le système Liberty Alliance est le principal exemple, chaque service gère une partie des données d'un utilisateur (l'utilisateur peut donc disposer de plusieurs comptes), mais partage les informations dont il dispose sur l'utilisateur avec les services partenaires.

Cette approche a été développée pour répondre à un besoin de gestion décentralisée des utilisateurs, où chaque service partenaire désire conserver la maîtrise de sa propre politique de sécurité, comme par exemple un ensemble de sites marchands indépendants d'un point de vue commercial et organisationnel.

Approche coopérative

L'approche coopérative, dont les systèmes Shibboleth et Central Authentication Service sont les principaux représentants, part du principe que chaque utilisateur dépend d'une des entités partenaires. Ainsi, lorsqu'il cherche à accéder à un service du réseau, l'utilisateur est authentifié par le partenaire dont il dépend. Comme dans l'approche fédérative, cependant, chaque service du réseau gère indépendamment sa propre politique de sécurité.

Normes et outils pour l'authentification unique

Quelle que soit la norme utilisée pour l'authentification unique, l'infrastructure sécurisée fait intervenir, entre le client et le serveur de service, un serveur d'authentification où est géré un identifiant ( www.siteweb.pays/ ou .siteweb.pays par exemple pour une authentification via un serveur OpenID).

Serveur d'authentification/identification

Même si l'authentification et l'identification sont deux choses différentes, il faut que ce serveur soit mis en place par un organisme lié aux transactions monétaires (particulier acheteur, professionnel). Aucune des sociétés de services internet vivant exclusivement de la publicité (payé par des professionnels) ne sont actuellement capables de vérifier et de garantir les données saisies par les internautes ; de plus chacune a développé son propre système d'authentification :

• Yahoo avec YahooID
• Microsoft avec Live ID
• Google avec Google Account

L'état ou un organisme sous son autorité, voire une société commerciale offrant un service réel (connexion internet/téléphonie/site de commerce), sont les seuls à pouvoir garantir ces deux paramètres.

Un standard Web pourrait venir d'une des trois implémentations classées par ordre d'ancienneté.

• Liberty Alliance implémenté par IBM dans leur produit et utilisé par Sun et Novell utilise que des jetons SAML.
• WS-Federation implémenté par Microsoft dans ces produits pour contrer Liberty. Geneva est le futur et proposera des jetons Kerberos et SAML.
• OpenID implémenté/utilisé par les sociétés clés de l'Internet (Yahoo!, Myspsace, Google, Microsoft...)

Un autre standard pourrait être un système de gestion d'identité local

• Sxipper: compatible OpenID et Firefox, il fonctionne sous Linux, Windows et MacOS.
• Windows CardSpace: compatible Microsoft.

Le problème des serveurs d'authentification est que lors de la saisie des identifiants et autre données personnelles, les services web gratuits ou les sites de commerces doivent laisser le choix du prestataire d'authentification, en sachant que de nombreux internautes arrêtent toute transaction face à la difficulté de remplir un formulaire.

Délégation d'authentification

Ils évitent de se connecter en mode visuel grace à l' utilisation d'API. Cette API permet à un service( role consumer) d'utiliser un autre service ( service provider) utilisant un identifiant sans avoir à divulguer de couple login/password. L'utilisateur tiers a ainsi accès de façon indirecte selon son groupe et son nom à un ensemble de fonctionnalités/données restreintes éventuellement par les droits d'accès dont il dispose. Ainsi on trouve comme protocoles de délégation :

• BBAuth (Browser-Based Authentication) mis en place par Yahoo
• AuthSub mis en place par Google
• OpenAuth mis en place par AOL
• FlickrAuth mis en place par Flickr
• Facebook Auth mis en place par Facebook
• Windows Live ID mis en place par Microsoft
• OAuth en fonctionnant coté bureau et internet.
• EGO mis en place par Symeos

Les sociétés souhaitant ce standard (Google,Yahoo,MySpace) se sont regroupées dans la fondation OpenSocial, suivies par des sociétés comme LinkedIn,Bebo,PLaxo. Seul Facebook fait cavalier seul sans doute du fait que FaceBook définit aussi un format standard d’échange de données personnelles sous le nom de FBML pour Facebook Markup Language.

Stockage

Les données sont stockées dans des bases d'utilisateurs variées : LDAP V3 (dont Active Directory), Postgresql, MySQL.

Format de données et d'échange

• L'adaptation du protocole DAP utilisé dans la norme X500 utilisé par les opérateurs téléphoniques sur TCP/IP a donné naissance à LDAP. Dans LDAP le format de données utilise un format non ASCII qui est une version allégée du Basic Encoding Rules (BER) appelée Lightweight Basic Encoding Rules (LBER). Le format d'échange a pour nom LDIF.

Proxy

Serveur faisant le lien entre un fournisseur de services et d'identités.

Le service compatible

Il permet en utilisant un identifiant unique d'éviter la saisie dans un formulaire d'informations nécessaire à créer un compte.

Protocoles

Différents protocoles ont été proposés pour échanger des informations liées à la sécurité, et notamment pour la mise en œuvre de systèmes d'authentification unique dans un cadre de sites indépendants les uns des autres :

• SAML a été développé par le consortium OASIS et est un protocole ouvert ;
• WS-Federation, proposé par Microsoft, constitue une solution concurrente;
• NuFW, basé sur des logiciels libres et qui permet de mettre en place une solution indépendante du protocole.

Références

Voir aussi

Articles connexes

• Identité nationale électronique sécurisée
• LDAP
• Kerberos
• OpenID
• Central Authentication Service
• LemonLDAP::NG
• Shibboleth
• Liberty Alliance
• Windows Live ID
• NTLM
• SAML
• Authentification forte
• OpenSSO
• JOSSO

Liens externes

• Présentation sur les SSO par le CRU
• Les livres blancs sur l'entreprise simple et bloquée choisissent Sign-On
• Comment améliorer des résultats d'affaires en le réduisant le service SVP coûte par Sign-On simple bloqué
• Un livre blanc d'Evidian sur les enjeux, les mythes et les réalités du SSO
• (en) Apache V2.x Cookie Authentication Module with memcached

• Portail de la sécurité informatique