Accueil > Développement > Single Sign-On

Single Sign-On

Le Single Sign-On est un principe assez important dans le cadre d’un SI complexe avec plusieurs applicatifs ou même dans l’ouverture à des clients externes.
Sans forcément s’en apercevoir, le SSO est devenu un principe très utilisé sur Internet, par exemple avec Google, Facebook, Microsoft et consorts.

Donc, aujourd’hui, je vais parler un peu de SSO.
Dans un premier temps, quelques généralités, exemples etc.
Et dans un second temps, les protocoles standards qui sont utilisés.

 

Généralités

 

Le Single Sign-On (en) (SSO) ou Authentification Unique (fr) en bon français est un processus permettant de se connecter à plusieurs applications à partir d’un seul et unique processus d’authentification. Le même nom est utilisé pour désigner le processus de connexion d’un utilisateur.
Une fois connecté au sein du SI d’origine, un utilisateur pourra accéder à autre SI sans avoir besoin de se connecter à ce dernier.
Dans le même esprit, on trouvera le Single Logout (SLO) ou Déconnexion Unique qui permet…de se déconnecter de tous les SI avec lesquels l’utilisateur s’est connecté en SSO.

Le principe repose sur, au moins, deux interlocuteurs de confiance (on parle de « Circle of Trust » pour désigner le groupement Idp-SPs).

Le premier est l’Identity Provider (Fournisseur d’Identités, IdP, ou Authorization Server). Son rôle est d’identifier et authentifier un utilisateur et, éventuellement, communiquer des autorisations.

Le deuxième est le Service Provider (Fournisseur de Services, SP, ou Ressource Server). Son rôle est de demander à l’IdP qui est l’utilisateur et ensuite lui donner accès (ou non) à différents services.

Dans le cadre du SSO, l’intérêt vient à partir du moment où il y a plusieurs interlocuteurs (1 IdP pour 1 SP reste d’un intérêt très limité).

 

Buts et intérêts

 

Il peut y avoir plusieurs buts et intérêts à utiliser le SSO.

Le premier aspect est la centralisation et la fédération : tous les utilisateurs sont présents dans un référentiel commun (annuaire ou autre), chaque service va demander tout ou partie des informations nécessaires. Le tronc commun est géré par l’IdP, les SP n’ont à gérer que les informations qui leurs sont spécifiques.

Le second aspect est pratique : un seul point unique pour sécuriser les informations d’identification, authentification et autorisations. Moins il y a de points a sécuriser, plus il est aisé d’investir (sachant qu’investir est différent de réussir).

Le troisième aspect est orienté utilisateur. En effet, l’utilisateur ne se connecte qu’une seule et unique fois à l’IdP et peut accéder à N SPs. Cela implique plusieurs éléments. Déjà, la facilité et la transparence et du gain de temps : l’utilisateur ne verra qu’une seule mire de connexion. Ensuite, il n’aura pas à se souvenir de N couples nom de compte – mot de passe.

Ce fait seul va permettre la réduction de la fatigue des mots de passe (en). La fatigue des mots de passe peut se résumer simplement : l’utilisateur va moins avoir de mots de passe à gérer, donc moins les réutiliser et il sera plus aisé de les renouveler, source des plus gros problèmes de sécurité. Ainsi, les mots de passe pourront être plus fort, renouveler plus souvent, etc.

NOTE : argument de moindre valeur lorsqu’un gestionnaire de mots de passe est utilisé (voir la partie Allez plus loin).

Le pendant, c’est qu’en perte de mot de passe, l’utilisateur n’a plus accès à rien 🙂

 

Exemples

 

Il y a de nombreux exemples de SSO que l’on peut utiliser en dehors d’un contexte professionnel.
Dans la vie de tous les jours d’un internaute, il est possible de rencontrer :

  • OpenID (OpenID (en), plus complet) qui est un standard ouvert et utilise OAuth (en) (IdP : Google, MyOpenID… ; SP : la galaxie Stack [Overflow, Exchange…], WordPress…)
  • LiveID qui est utilisé pour les sites Microsoft mais aussi pour le système (Windows 10 par exemple)
  • Compte Google utilisé par…Google (YouTube, Google+, Google Drive, GMail… mais aussi Feedly…)
  • Facebook Connect (en) qui est la déclinaison de Facebook pour pouvoir se connecter à des apps ou site web via Facebook (et qui a remplacé OpenID)

Le SSO est donc très, très présent. C’est une facilité pour l’utilisateur mais qui a le défaut de son intérêt : la centralisation.

 

Quelques réflexions avant la mise en place du SSO

 

C’est un peu évident, mais la première question reste de savoir…pourquoi utiliser un SSO.
Si c’est un SSO au sein de l’entreprise pour communiquer avec les applicatifs internes ou si c’est pour permettre à des clients de se connecter depuis leurs propres SI, les contraintes ne seront pas les mêmes.

Dans tous les cas, il faut tout de même se poser la question de la Gestion des identités et des accès (Identity management et Identity management system).
Savoir comment gérer ces utilisateurs : leur identification, authentification et gestion de droits d’accès est un prérequis au SSO.
Sinon, c’est le mur assuré.

Ensuite, et c’est d’autant plus si l’on doit s’interfacer avec des clients, il faut bien identifier comment les utilisateurs vont être créés, mis à jour et supprimés (logiquement ou physiquement). On parle ici de User provisioning (en).

Enfin, la dernière question et non des moindres : comment sécuriser les échanges ?
Par exemple, dans le cadre d’un échange avec un autre SI, on va pouvoir jouer sur les certificats : 1 certificat = 1 partenaire qui est identifié ainsi. Il est aussi possible de chiffrer et signer les flux (en dehors du HTTPS classique).

 

Standards

 

Quand on attaque le SSO, il y a toujours le moyen de le faire à la main.
On va passer rapidement sur cette option un peu bête (réinventer la roue, c’est le risque de la faire carrée).

Il existe plusieurs standards. OAuth et OpenID en sont deux, Security Assertion Markup Language (SAML) en est un autre.

SAML est un standard ouvert basé sur du XML et géré par OASIS (Organization for the Advancement of Structured Information Standards).
Il existe plusieurs versions du SAML dont la v2.0 est devenue un standard en…2005.
Alors certes, ça devient un peu vieux, mais c’est bien mature et, pour le coup, ça fonctionne bien.
SAML se base surtout sur des requêtes HTTP visible donc par le navigateur.

D’ailleurs, la documentation de ComponentSpace (qui fournit une librairie pour .Net/.Net Core) est très intéressante. ComponentSpace SAML v2.0 for ASP.NET Downloads, voir le « ComponentSpace SAML v2.0 Developer Guide ».

Pour ce qui est du User Provisioning, deux autres standards peuvent être utilisés.
Le premier est le Service Provisioning Markup Language (SPML) également standardisé par OASIS et basé sur du XML, mais daté de 2006.

Un autre est le System for Cross-domain Identity Management (SCIM). Plus récent, il est supporté par Google, Microsoft, Salesforce (pour ne citer qu’eux) et décrit une API REST au format XML ou JSON.

 

Conclusion

 

Le tour d’horizon de ce billet est donc relativement rapide (c’est sans compter les liens !) mais présente plusieurs éléments structurants.

Au final, il n’y a aucune raison valable pour implémenter un SSO à la main.
Pire, ce sera probablement plus dangereux et faillible que les standards établis (c’est un peu le but, quand même…).

Pour avoir utilisé le SAML via le composant de ComponentSpace, j’avoue que ça a été assez rapide et trivial à réaliser.
Deux choix d’API sont proposés : High Level où les développeurs utilisent deux-trois méthodes qui fonctionnent en boite noire à partir d’une configuration (depuis un fichier saml.config ou créée à la main) et Low Level où il faut se frapper beaucoup plus de code (et donc de risque d’erreurs).

 

Allez plus loin

 

Les standards SSO

User Provisioning

Gestion des mots de passe

Publicités
Catégories :Développement
  1. Aucun commentaire pour l’instant.
  1. No trackbacks yet.

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :