Comment fonctionne l'authentification unique?

Qu'est-ce que l'authentification unique ?

Single sign-on (SSO) is an authentication method that enables users to securely authenticate with multiple applications and websites by using just one set of credentials.

Comment la SSO fonctionne-t-elle ?

La SSO fonctionne sur la base d'une relation de confiance établie entre une application, appelée fournisseur de services, et un fournisseur d'identités, comme OneLogin. Une telle relation de confiance repose souvent sur un certificat, échangé entre le fournisseur d'identités et le fournisseur de services. Ce certificat peut servir à signer les informations d'identité que le fournisseur d'identités envoie au fournisseur de services, pour que ce dernier sache qu'elles proviennent d'une source fiable. Dans la SSO, ces données d'identité prennent la forme de jetons qui contiennent des éléments d'information permettant d'identifier l'utilisateur, tels que son adresse e-mail ou son nom d'utilisateur.

La procédure de connexion se déroule généralement comme suit :

1. Un utilisateur navigue jusqu'à l'application ou le site Web auquel il veut accéder, c'est-à-dire le fournisseur de services.
2. Le fournisseur de services envoie un jeton contenant certaines informations à propos de l'utilisateur (son adresse e-mail, par exemple) au système SSO, c'est-à-dire le fournisseur d'identités, dans le cadre d'une demande d'authentification de l'utilisateur.
3. Le fournisseur d'identités contrôle d'abord si l'utilisateur s'est déjà authentifié, auquel cas il lui octroie l'accès à l'application du fournisseur de services et passe directement à l'étape 5.
4. Si l'utilisateur ne s'est pas connecté, il sera invité à le faire en renseignant les identifiants requis par le fournisseur d'identités. Il peut s'agir simplement d'un nom d'utilisateur et d'un mot de passe, mais peut inclure d'autres formes d'authentification comme un mot de passe à usage unique (OTP).
5. Une fois que le fournisseur d'identités valide les identifiants renseignés, il renverra un jeton au fournisseur de services pour confirmer la réussite de l'authentification.
6. Ce jeton est transmis au fournisseur de services par le biais du navigateur de l'utilisateur.
7. Ce jeton que reçoit le fournisseur de services est validé en vertu de la relation de confiance qui a été établie entre le fournisseur de services et le fournisseur d'identités au moment de la configuration initiale.
8. L'utilisateur se voit octroyer l'accès au fournisseur de services.

Si l'utilisateur tente d'accéder à un autre site Web, il faudra alors qu'une même relation de confiance soit configurée entre ce nouveau site Web et la solution SSO, puis la procédure d'authentification se déroulera en suivant les mêmes étapes.

Qu'est-ce qu'un jeton SSO ?

Un jeton SSO est une collection de données ou d'informations qui est transmise d'un système à un autre au cours du processus SSO. Ces données peuvent être simplement l'adresse e-mail de l'utilisateur et les informations concernant le système qui envoie le jeton. Les jetons doivent être signés numériquement pour que le récepteur du jeton puisse s'assurer que le jeton provient d'une source fiable. Le certificat utilisé pour la signature numérique est échangé au moment de la configuration initiale.

La SSO est-elle sécurisée ?

À cette question, nous répondrons : « Cela dépend. »

Pour nombre de raisons, la SSO peut améliorer la sécurité. Une solution d'authentification unique peut simplifier la gestion des noms d'utilisateur et mots de passe à la fois pour les utilisateurs et les administrateurs. Les utilisateurs n'ont plus besoin d'archiver des différents jeux d'identifiants et peuvent se contenter de mémoriser un seul mot de passe plus complexe. Souvent, la SSO permet juste aux utilisateurs d'accéder plus rapidement à leurs applications.

La SSO peut permettre également de réduire le temps que le service d'assistance doit consacrer aux utilisateurs ayant perdu leurs mots de passe. Les administrateurs peuvent contrôler les exigences de façon centralisée, telles que la complexité des mots de passe et l'authentification à plusieurs facteurs (MFA). Les administrateurs peuvent également renoncer plus rapidement aux privilèges d'accès, à tous les niveaux, lorsqu'un utilisateur quitte l'organisation.

Mais l'authentification unique présente aussi des inconvénients. Par exemple, il se peut que vous vouliez verrouiller un peu plus certaines applications. Pour cette raison, il conviendrait d'opter pour une solution SSO qui vous offre certaines possibilités (par exemple, exiger un facteur d'authentification supplémentaire avant qu'un utilisateur se connecte à une application spécifique) ou qui empêche les utilisateurs d'accéder à certaines applications en l'absence d'une connexion à un réseau sécurisé.

Comment l'authentification unique est-elle implémentée ?

Selon la solution SSO que vous utilisez, les modalités d'implémentation ne seront pas les mêmes. Cependant, quelles que soient les étapes spécifiques, vous devez vous assurer d'avoir défini des objectifs et des buts clairs pour votre implémentation. Prenez soin de répondre aux questions suivantes :

• Quels sont les différents profils d'utilisateurs auxquels vous proposez des services et quels sont leurs besoins distincts ?
• Êtes-vous à la recherche d'une solution sur site ou d'une solution cloud ?
• Cette solution pourra-t-elle évoluer au rythme de votre entreprise et de vos besoins ?
• Quelles fonctionnalités recherchez-vous pour veiller à ce que seuls les utilisateurs fiables puissent se connecter ? MFA, authentification adaptative, confiance dans les appareils, mise sur liste verte des adresses IP, etc. ?
• À quels systèmes ces fonctionnalités doivent-elles être intégrées ?
• Avez-vous besoin d'un accès aux API ?

Que doit offrir un véritable système SSO ?

Il est important de comprendre la différence entre une authentification unique et le stockage de mots de passe ou l'utilisation de gestionnaires de mots de passe, parfois également appelés « SSO », ce qui pourrait signifier ici « Same Sign-on » (authentification identique) plutôt que « Single Sign-on » (authentification unique). Avec une solution de stockage de mots de passe, vous disposez d'une paire nom d'utilisateur/mot de passe unique, mais vous devez saisir vos identifiants chaque fois que vous accédez à un nouveau site Web ou à une nouvelle application. Le système de stockage de mots de passe consiste simplement à stocker vos identifiants pour les diverses applications et à les insérer lorsque nécessaire. Il n'existe aucune relation de confiance établie entre les applications et le système de stockage de mots de passe.

Avec une solution SSO, au sens d'« authentification unique », une fois connecté via celle-ci, vous pouvez accéder à l'ensemble des applications et des sites Web approuvés par l'entreprise sans devoir vous reconnecter. Il s'agit notamment des applications cloud et sur site, souvent accessibles via un portail SSO (également appelé portail de connexion).

Quelle est la différence entre un logiciel SSO et une solution SSO ?

En vous renseignant sur les options SSO disponibles, vous avez peut-être remarqué qu'elles sont désignées parfois « logiciel SSO », parfois « solution SSO », ou encore « fournisseur SSO ». Dans la plupart des cas, la différence entre ces options SSO réside simplement dans le positionnement choisi par les entreprises. Le terme « logiciel » suggère l'installation sur site d'un produit. Il est généralement conçu pour exécuter un ensemble spécifique de tâches et rien d'autre. Le terme « solution » suggère la possibilité d'étendre ou de personnaliser les fonctionnalités du produit standard. Le terme « fournisseur » est employé pour faire référence une entreprise qui produit ou héberge la solution. Par exemple, OneLogin est communément appelé fournisseur de solutions SSO.

Existe-t-il différents types de SSO ?

S'agissant de l'authentification unique (SSO), de nombreux termes sont employés.

• Gestion des identités fédérées (FIM)
• OAuth (plus spécifiquement, OAuth 2.0 de nos jours)
• OpenID Connect (OIDC)
• Security Access Markup Language (SAML)
• Authentification identique (SSO)

La SSO fait en réalité partie d'un concept plus large intitulé « Gestion des identités fédérées ». C'est pourquoi la SSO est parfois appelée « SSO fédérée ». La FIM fait référence simplement à une relation de confiance nouée entre plusieurs domaines ou systèmes de gestion des identités. L'authentification unique est souvent une fonctionnalité disponible dans une architecture FIM.

OAuth 2.0 est un framework spécifique qui pourrait également être considéré comme faisant partie d'une architecture FIM. OAuth 2.0, en se focalisant sur cette relation fiable, autorise l'échange inter-domaines d'informations sur l'identité des utilisateurs.

OpenID Connect (OIDC) est une couche d'authentification venant compléter OAuth 2.0 pour offrir une fonctionnalité d'authentification unique.

Security Access Markup Language (SAML) est un standard ouvert également conçu pour offrir une fonctionnalité d'authentification unique.

L'authentification identique, également désignée SSO, se distingue en fait de l'authentification unique en cela qu'elle n'implique aucune relation de confiance entre les entités qui procèdent à l'authentification. Elle s'appuie plutôt sur la duplication des identifiants entre les systèmes et la simple transmission de ces identifiants lorsque nécessaire. Elle n'offre pas un niveau de sécurité équivalent à une solution d'authentification unique.

En outre, certains systèmes spécifiques sont communément évoqués lors des discussions portant sur l'authentification unique : Active Directory, Active Directory Federation Services (ADFS) et Lightweight Directory Access Protocol (LDAP).

Active Directory, officiellement désigné Active Directory Directory Services (ADDS) de nos jours, est un service d'annuaire centralisé de Microsoft. Les utilisateurs et les ressources sont ajoutés au service d'annuaire à des fins de gestion centrale et ADDS utilise des protocoles d'authentification comme NTLM et Kerberos. Ainsi, les utilisateurs qui font partie d'ADDS peuvent s'authentifier depuis leur ordinateur et accéder à d'autres systèmes s'intégrant à ADDS. C'est une forme d'authentification unique.

Active Directory Federation Services (ADFS) est un type de système de gestion des identités fédérées qui fournit également des fonctionnalités d'authentification unique. Il prend en charge les standards SAML et OIDC. ADFS est principalement utilisé pour établir la confiance entre ADDS et d'autres systèmes, tels qu'Azure AD ou d'autres forêts ADDS.

Lightweight Directory Access Protocol (LDAP) est tout simplement un standard du secteur qui définit la façon d'organiser les informations des annuaires et de lancer des requêtes pour extraire une partie de ces informations. LDAP vous permet de gérer les ressources (comme les utilisateurs et les systèmes) de manière centralisée. Toutefois, ce standard ne définit pas la méthode de connexion à ces systèmes. En d'autres termes, il ne définit pas les protocoles réels utilisés dans l'authentification. Néanmoins, il est souvent utilisé dans le cadre des processus d'authentification et de contrôle des accès. Par exemple, avant qu'un utilisateur puisse accéder à une ressource spécifique, LDAP peut être utilisé pour lancer une requête concernant cet utilisateur et tous les groupes auxquels il appartient, de façon à voir si l'utilisateur en question a accès à une telle ressource. Les solutions LDAP comme OpenLDAP offre bien des fonctionnalités d'authentification via les protocoles d'authentification qu'elles prennent en charge, comme Simple Authentication and Security Layer (SASL).

Qu'entend-t-on par « logiciel SSO en tant que service » ?

Tout comme bien d'autres applications, les fonctionnalités SSO ont été converties de façon à fonctionner directement sur Internet. Les plateformes comme OneLogin qui fonctionnent dans le Cloud peuvent alors entrer dans la catégorie des solutions SSO de type SaaS (Software as a Service, littéralement « logiciel en tant que service »).

Qu'est-ce que la SSO d'application à application ?

Enfin, vous avez peut-être entendu parler de SSO App-to-App ou Application-to-Application. Ce n'est pas encore tout à fait une norme de l'industrie. C'est davantage un terme qui a été utilisé par SAPCloud pour décrire le processus de transmission d'une identité d'utilisateur d'une application à une autre au sein de leur écosystème. Il est quelque peu similaire à OAuth 2.0 mais encore une fois, ce n'est pas un protocole ou une méthode standard et est actuellement spécifique à SAPCloud.