Single Sign-On (SSO)

Dans le monde numérique actuel, où nous utilisons quotidiennement de nombreuses applications et plateformes, gérer différents identifiants est devenu un défi.

Se connecter et se déconnecter continuellement de différents systèmes peut être chronophage et frustrant, et se souvenir de plusieurs mots de passe peut conduire à des pratiques peu sûres, telles que l’utilisation de mots de passe trop simples ou leur annotation.

C’est ici que le Single Sign-On (SSO) intervient. Cet article approfondit ce qu’est le SSO, comment il fonctionne et pourquoi il est si important dans l’environnement numérique actuel.

Qu’est-ce que le Single Sign-On (SSO) ?

Le Single Sign-On, ou SSO, permet aux utilisateurs de se connecter une seule fois. Le logiciel SSO s’occupe ensuite de l’authentification automatique pour d’autres applications.

Cela signifie qu’après s’être connecté à une application, les utilisateurs ont automatiquement accès à toutes les autres applications pour lesquelles ils sont autorisés, sans avoir à se reconnecter.

Cela représente un changement considérable par rapport à il y a quelques années, quand un petit ensemble d’applications était tout ce qu’un utilisateur avait besoin pour travailler.

Dans l’environnement numérique actuel, où les utilisateurs doivent souvent accéder à des dizaines d’applications différentes, le SSO offre une solution efficace et conviviale pour gérer les droits d’accès.

Avantages du Single Sign-On (SSO)

• Facilité d’utilisation : Les utilisateurs n’ont besoin de se souvenir que d’un seul ensemble d’identifiants, simplifiant et accélérant le processus de connexion.
• Productivité accrue : Moins de temps passé à se connecter signifie plus de temps pour le travail réel.
• Sécurité améliorée : En réduisant le nombre d’identifiants à retenir, le SSO diminue les risques d’utiliser des mots de passe peu sûrs.
• Gestion efficace des droits d’accès: Les administrateurs peuvent facilement gérer quels utilisateurs ont accès à quelles applications, le tout à partir d’un point central.
• Moins de support IT: Avec moins de mots de passe oubliés à réinitialiser, les équipes informatiques peuvent consacrer leur temps à des tâches plus importantes.

Inconvénients du Single Sign-On (SSO)

• Point de défaillance unique : Si la solution SSO tombe en panne, les utilisateurs peuvent ne pas pouvoir accéder à aucune application.
• Risques de sécurité : Si les identifiants d’un utilisateur sont compromis, un attaquant peut potentiellement accéder à toutes les applications pour lesquelles l’utilisateur est autorisé.
• Problèmes de compatibilité : Toutes les applications ne prennent pas en charge le SSO, ce qui peut entraîner des incohérences dans l’expérience utilisateur.

Le risque du Single Sign-On est que, une fois connecté, vous avez accès à tout. Il est donc fortement recommandé de combiner chaque solution SSO avec un niveau supplémentaire d’authentification. (authentification à deux facteurs).

Quelle est la sécurité du SSO ?

Le Single Sign-On (SSO) est conçu pour améliorer à la fois la convivialité et la sécurité. En réduisant le nombre d’identifiants que les utilisateurs doivent retenir, le SSO diminue les risques d’utiliser des mots de passe peu sûrs, telles que l’utilisation de mots de passe trop simples ou leur annotation.

De plus, avec le SSO, les administrateurs peuvent facilement surveiller et gérer quels utilisateurs ont accès à quelles applications, ce qui aide à prévenir les accès non autorisés.

Cependant, comme pour toute solution de sécurité, le SSO n’est pas sans risques. Si les identifiants d’un utilisateur sont compromis, un attaquant peut potentiellement accéder à toutes les applications pour lesquelles l’utilisateur est autorisé. Il est donc important de combiner le SSO avec d’autres mesures de sécurité, comme des exigences de mots de passe forts, des changements réguliers de mots de passe, et éventuellement même. une authentification multi-facteurs (MFA).

La MFA est une méthode de sécurité où les utilisateurs doivent fournir deux preuves ou plus (ou facteurs) pour vérifier leur identité. Ces facteurs peuvent être quelque chose que l’utilisateur sait (comme un mot de passe), quelque chose que l’utilisateur possède (comme un jeton de sécurité ou un appareil mobile), ou quelque chose que l’utilisateur est (comme une empreinte digitale ou une autre caractéristique biométrique). En combinant le SSO avec la MFA, les organisations peuvent offrir la convivialité du SSO tout en maintenant un niveau de sécurité plus élevé.

Il existe également des alternatives au SSO, telles que la gestion d’identité fédérée, où les informations d’identité sont partagées entre différentes organisations, et l’authentification basée sur le risque, où le niveau d’authentification est ajusté en fonction du niveau de risque de l’utilisateur et de la transaction. Cependant, ces solutions ont leurs propres avantages et inconvénients et peuvent être plus complexes à mettre en œuvre que le SSO.

Pour ceux qui recherchent une solution complète à la fois conviviale et sécurisée, HelloID peut être le choix idéal. Avec HelloID. vous pouvez profiter des avantages du SSO, tout en mettant en œuvre d’autres fonctionnalités de sécurité avancées, telles que l’authentification multi-facteurs. Contactez-nous dès aujourd’hui pour découvrir comment HelloID peut vous aider.

Téléchargez notre livre blanc

Comment fonctionne le Single Sign-On ?

L’idée de base du SSO est que chaque application dont une personne a besoin est accessible en se présentant une seule fois. Les applications doivent donc d’une manière ou d’une autre savoir que vous avez déjà été validé. Avec une bonne solution SSO, les applications modernes ne conservent pas une copie des identifiants, mais se fient simplement à ce qu’on appelle un fournisseur d’identité (IdP).

Avant d’expliquer comment cela fonctionne, examinons d’abord la terminologie et les définitions associées.

Pour utiliser une application ou accéder à un réseau sécurisé, vous devez pouvoir vous identifier. Cela se fait souvent avec une combinaison d’un nom d’utilisateur unique et d’un mot de passe. La combinaison d’un nom d’utilisateur et d’un mot de passe est une forme d’authentification.

Fournisseur d’identité (IdP):
C’est là que les identifiants sont stockés. Toute l’authentification se produit ici. Un fournisseur d’identité peut être, par exemple, le Active Directory local, Azure AD ou, par exemple, notre solution Cloud IDaaS,  HelloID.

Fournisseur de services (SP):
C’est le système ou l’application auquel un utilisateur accède et qui nécessite une vérification. Lorsqu’un utilisateur ouvre une application, les fournisseurs de services et d’identité communiquent entre eux pour vérifier l’identité de l’utilisateur. Si le fournisseur d’identité identifie positivement l’utilisateur, il est autorisé à accéder à l’application.

Revendication:
Une revendication est un paquet d’informations envoyé de l’IdP au SP. Le contenu d’une revendication varie selon le protocole SSO (par exemple, SAML, OAuth ou OpenID), mais contient généralement l’ID unique, le nom et divers autres attributs. Elle est signée et chiffrée par un certificat auquel l’IdP et le SP ont accès. Cela permet au SP de s’assurer que les informations proviennent d’une source fiable.

Voici un aperçu détaillé de la façon dont le SSO fonctionne:

1. Authentification des utilisateurs : L’utilisateur se connecte à un serveur d’authentification central, également connu sous le nom de fournisseur d’identité (IdP). Cela peut être, par exemple, le Active Directory local, Azure AD ou, par exemple, notre solution Cloud IDaaS HelloID.
2. Session SSO : Après une authentification réussie, l’IdP démarre une session SSO. Cela se fait généralement en plaçant un cookie dans le navigateur de l’utilisateur.
3. Accès aux applications : Lorsqu’un utilisateur lance une application, les fournisseurs d’identité et de services interagissent pour authentifier l’utilisateur. Si l’authentification est confirmée par le fournisseur d’identité, l’accès à l’application est accordé à l’utilisateur.
4. Vérification de l’authentification : Le fournisseur d’identité (IdP) examine l’état de la session SSO. Si l’utilisateur est déjà authentifié, l’IdP envoie une assertion au fournisseur de services (SP) avec les détails d’authentification de l’utilisateur. Cette assertion est sécurisée par un certificat accessible à la fois par l’IdP et le SP.
5. Octroi de l’accès : Sur la base de l’assertion reçue, le SP permet à l’utilisateur d’accéder à l’application sans nécessiter une nouvelle connexion. Ceci élimine le besoin pour les SP de stocker les identifiants de connexion.

Il est important de noter que ceci est un aperçu simplifié et que les étapes spécifiques peuvent varier selon la solution SSO utilisée et la configuration des applications.

En termes simples, le SSO fonctionne grâce à une relation de confiance établie entre le fournisseur d’identité (IdP) et le fournisseur de services (SP). Ainsi, lorsque l’IdP atteste qu’un utilisateur est bien « Jan Jansen », le SP accepte cette affirmation et connecte l’utilisateur sous le compte de « Jan Jansen ».

La relation de confiance est mise en place par l’administrateur des systèmes. Les informations du fournisseur d’identité (IdP) sont transmises au fournisseur de services (SP), accompagnées d’un certificat, et vice versa. Lorsqu’un utilisateur ouvre une application, l’IdP utilise le certificat pour signer et chiffrer une assertion. Cette assertion est ensuite envoyée au SP au lieu des identifiants de connexion de l’utilisateur. Le SP déchiffre et vérifie cette information.

Sécurité accrue grâce à la confiance : Grâce à cette relation de confiance, les SP n’ont pas besoin de stocker les identifiants de connexion de manière conventionnelle.

Fonctionnement pratique du Single Sign-On :

Après avoir expliqué le fonctionnement général du SSO, voyons comment cela se passe en pratique : Comment un utilisateur gère-t-il l’ouverture d’une application et comment un SP sait-il qu’il doit vérifier avec l’IdP ?

La plupart des IdP de Single Sign-On offrent des portails d’applications. Ce sont généralement des applications web accessibles dans le monde entier. Dès qu’un utilisateur se connecte au portail avec ses identifiants, il accède à toutes les applications et ressources nécessaires à son travail. Lorsqu’il sélectionne une application, une confirmation SSO est envoyée au SP avec les informations de l’utilisateur. Si l’assertion est acceptée, l’utilisateur est redirigé vers l’application et peut commencer à travailler immédiatement ! Ce type d’activité SSO est appelé « initié par l’IdP », car il provient du fournisseur d’identité lui-même.
La plupart des fournisseurs d’identité (IdP) de Single Sign-On disposent de portails d’applications, souvent basés sur le web, accessibles partout dans le monde. Dès qu’un utilisateur se connecte au portail avec ses identifiants, il obtient l’accès à toutes les applications et ressources nécessaires pour son travail. Lorsqu’il choisit une application, une confirmation SSO est envoyée au fournisseur de services (SP) avec les informations de l’utilisateur. Si l’assertion est validée, l’utilisateur est redirigé vers l’application et peut commencer à travailler immédiatement. Ce processus est connu sous le nom de SSO ‘initié par l’IdP’.

Et si l’utilisateur n’accède pas d’abord au portail ? Que se passe-t-il, par exemple, s’il se rend directement sur Gmail via son navigateur ? Dans de tels cas, le SP détermine la marche à suivre en fonction du nom d’utilisateur ou du domaine email de l’utilisateur. Au lieu de demander des identifiants, le SP utilise les informations fournies par l’IdP pour savoir où router la demande d’authentification. Ce type de requête est appelé « initié par le SP », car la demande de SSO provient du fournisseur de services.

[1] https://www.businesswire.com/news/home/20170918005033/en/Information-App-Overload-Hurts-Worker-Productivity-Focus

En savoir plus sur le Cloud Single Sign-On