De nos jours, une grande partie des en­tre­prises fran­çaises sont actives sur les réseaux sociaux, beaucoup utilisent les avantages des services Cloud, mais aussi de leurs appareils mobiles, tels que les smart­phones et les tablettes. Une quantité in­croyable de mots de passe à se remémorer vient ainsi s’ajouter à ceux qui occupent déjà notre esprit pour nos comptes de mes­sa­ge­rie privés et de réseaux sociaux.

Rien d’étonnant, donc, à ce que le commun des in­ter­nautes souffre d’une « fatigue des mots de passe chronique » (password fatigue) – un syndrome qui pousse l’uti­li­sa­teur à recourir à des suites de chiffres simples comme « 12345 » ou à noter ces prin­ci­paux mots de passe sur des post-its collés sur son écran d’or­di­na­teur. Ceci entraîne à long terme non seulement un manque de pro­duc­ti­vité, mais aussi un défaut de sécurité des données. La solution ? Le Single Sign-On (SSO) ou au­then­ti­fi­ca­tion unique. Mais que signifie exac­te­ment ce terme et quelle sécurité offre cette procédure d’au­then­ti­fi­ca­tion populaire ?

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

Dans le domaine in­for­ma­tique, le Single Sign-On, également traduit par « au­then­ti­fi­ca­tion unique », désigne une procédure d’au­then­ti­fi­ca­tion, qui suit toujours le même dé­rou­le­ment :

  1. Un uti­li­sa­teur se connecte une seule fois à son poste de travail.
  2. Il a ainsi accès à tous les or­di­na­teurs et services (y compris le Cloud), pour lesquels il dispose d’une au­to­ri­sa­tion lo­ca­le­ment tant qu’il reste sur le même poste de travail.
  3. Tous les droits d’accès sont annulés dès que l’uti­li­sa­teur se dé­con­necte de ce poste. Cette dé­con­nexion peut se produire après un délai défini au préalable ou lorsque l’uti­li­sa­teur exécute ma­nuel­le­ment un single sign-out ou single sign-off.

Le SSO est ainsi une procédure d’accès à de multiples ap­pli­ca­tions associées les unes aux autres, mais in­dé­pen­dantes, qui permet à l’uti­li­sa­teur de se connecter une seule fois au lieu de saisir ses données d’accès in­di­vi­duel­le­ment à chaque connexion à un logiciel. Du fait de leur con­vi­via­lité, les pro­cé­dures Single Sign-On sont aussi bien utilisées dans un cadre privé (ap­pli­ca­tions Web et Cloud privés) que pro­fes­sion­nel (ap­pli­ca­tions utilisées dans une en­tre­prise et portail sur l’Intranet).

Comment fonc­tionne le Single Sign-On ?

Lorsqu’un in­ter­naute souhaite se connecter à plusieurs services et ap­pli­ca­tions pendant une session, il doit en général saisir ses données d’accès sé­pa­ré­ment pour chaque service et ap­pli­ca­tion. Toutefois, s’il s’est inscrit à un service Single Sign-On, cette tâche est réalisée par un logiciel en amont qui dispose de toutes les données d’accès de l’uti­li­sa­teur et l’au­then­ti­fie au­to­ma­ti­que­ment sur tous les autres services sans qu’il ait besoin d’in­ter­ve­nir. Pour ce faire, il utilise une identité unique globale de l’uti­li­sa­teur (similaire à une identité VIP), qui est connue de toutes les ap­pli­ca­tions con­cer­nées et con­si­dé­rée comme fiable du fait de la ré­pu­ta­tion du service SSO.

Dif­fé­rents systèmes d’au­then­ti­fi­ca­tion et d’au­to­ri­sa­tion sont utilisés pour permettre un fonc­tion­ne­ment fluide de la procédure Single Sign-On :

OpenID

OpenID est un standard d’au­then­ti­fi­ca­tion ouvert utilisé pour plus d’un milliard de comptes, notamment pour Google, WordPress et PayPal. La dernière version du système est intitulée OpenID Connect (OIDC) et se présente comme une com­bi­nai­son de OpenID et OAuth2. Lorsqu’OpenID est utilisé dans le cadre d’une procédure Single Sign-On, l’uti­li­sa­teur a besoin d'un compte OpenID qu’il peut obtenir auprès d’un four­nis­seur d’identité OpenID (par ex. Google). Ce compte (ou l’URL cor­res­pon­dante) permet à l’uti­li­sa­teur de se connecter sur tous les sites Internet sup­por­tant OpenID. Le four­nis­seur d’identité transmet dans ce cadre un « jeton » servant de preuve de l’identité de l’uti­li­sa­teur auprès du site Internet en question.

On peut se re­pré­sen­ter fi­gu­ra­ti­ve­ment l’uti­li­sa­tion de SSO via OpenID comme un voyage au cours duquel on traverse une frontière : le voyageur (uti­li­sa­teur) utilise à cet effet un passeport émis par un gou­ver­ne­ment (four­nis­seur d’identité) en qui le pays de des­ti­na­tion (site Internet) a toute confiance. Ce passeport permet de vérifier l’identité du voyageur. Le bouton « Se connecter avec Facebook », présent sur de nombreux sites Internet, en est un bon exemple.

OAuth2

Con­trai­re­ment à OpenID, OAuth2 est plutôt un standard d’au­to­ri­sa­tion qu’un standard d’au­then­ti­fi­ca­tion. La prin­ci­pale dif­fé­rence est que, plutôt que de s’au­then­ti­fier sur un site Internet, l’uti­li­sa­teur délègue cette tâche à un client qui se connecte au site Internet à l’aide d’un jeton du four­nis­seur d’identité. L’avantage est que l’uti­li­sa­teur n’a pas à trans­mettre ses données au site Internet concerné.

La métaphore qui con­vien­drait davantage ici est celle du « gar­dien­nage de maison » : en tant que pro­prié­taire d’une maison (uti­li­sa­teur), si l’on transmet ses clés à un ami (Client), ce dernier est autorisé à pénétrer dans la maison (site Internet). OAuth2 est par exemple utilisé pour importer des amis d’un compte Facebook dans un autre service, sans que les in­for­ma­tions Facebook soient trans­mises à ces services.

Remarque

La dif­fé­rence de sig­ni­fi­ca­tion entre les termes in­for­ma­tiques « au­then­ti­fi­ca­tion » et « au­to­ri­sa­tion » étant faible, ils sont souvent confondus ou utilisés à tort comme synonymes. L’au­then­ti­fi­ca­tion a lieu lorsqu’un service identifie un uti­li­sa­teur à l’aide de ses données d’accès. Dans le cas d’une au­to­ri­sa­tion, l’uti­li­sa­teur accorde à un service l’au­to­ri­sa­tion d’utiliser certaines données et fonc­tion­na­li­tés de son profil.

SAML

SAML est le plus ancien des trois systèmes men­tion­nés et sert de standard ouvert aussi bien pour l’au­then­ti­fi­ca­tion que pour l’au­to­ri­sa­tion dans une procédure SSO. Ici aussi, une dis­tinc­tion est opérée entre trois parties : l’uti­li­sa­teur (nommé : principal), le site Internet (nommé : service provider) et le four­nis­seur d’identité qui procède à la vé­ri­fi­ca­tion. Le dé­rou­le­ment est très proche de celui observé pour OpenID. La métaphore du voyage est donc également ap­pli­cable ici.

Dans le cas de SAML, le site Internet émet toutefois, dans tous les cas, une demande d’iden­ti­fi­ca­tion active envoyée au four­nis­seur d’identité sous la forme d’un message XML et men­tion­nant les in­for­ma­tions né­ces­saires. Le four­nis­seur d’identité y répond avec une assertion contenant les in­for­ma­tions d’au­then­ti­fi­ca­tion et d’au­to­ri­sa­tion demandées ainsi que les attributs spé­ci­fiques, tels que l’adresse e-mail et le numéro de téléphone de l’uti­li­sa­teur. SAML peut donc également être comparé à l’émission de documents ad­mi­nis­tra­tifs per­son­nels sur demande du pays de des­ti­na­tion.

Approches de solution pour Single Sign-On

Dans la pratique in­for­ma­tique, on distingue prin­ci­pa­le­ment trois approches de solutions pour la réa­li­sa­tion des pro­cé­dures SSO :

Solution sous forme de portail

Comme son nom l’indique, dans le cadre de cette solution SSO, l’uti­li­sa­teur se connecte sur un portail, c’est-à-dire un système intégrant les ap­pli­ca­tions, les processus et les services. Une fois l’au­then­ti­fi­ca­tion réussie, le portail fournit à l’uti­li­sa­teur un marqueur d’iden­ti­fi­ca­tion global (par exemple un cookie) lui donnant accès à toutes les fonc­tion­na­li­tés intégrées dans le portail. Le compte Google en est un bon exemple : une ins­crip­tion et une connexion uniques per­met­tent un accès immédiat à d’autres services du groupe in­for­ma­tique comme le Google Play Store ou Google Mail.

Système de ticketing

Le nom de cette solution SSO est une fois encore évocateur : elle met l’accent sur un réseau de services connus. Lorsque l’uti­li­sa­teur se connecte à l’un de ces services, un ticket virtuel lui est attribué pour l’iden­ti­fi­ca­tion vis-à-vis de tous les autres par­ti­ci­pants à ce « cercle de confiance ». Le service d’au­then­ti­fi­ca­tion Kerberos ainsi que le Liberty Alliance Project en sont des exemples.

Solution locale

Dans le cas d’une solution Single Sign-On locale, un client SSO est en général installé sur le poste de travail utilisé ré­gu­liè­re­ment. Il est configuré de façon à ce que les données d’accès pour l’ensemble des ap­pli­ca­tions et services né­ces­saires soient obtenues à partir d’un fichier local chiffré placé sur le disque dur, d’un serveur du réseau local ou d’une base de données et soient au­to­ma­ti­que­ment saisies dans la fenêtre de connexion ouverte. Les services de mots de passe des na­vi­ga­teurs comme Safari ou Chrome sont par exemple des clients SSO de ce type. L’uti­li­sa­tion d’un « jeton » physique comme support des in­for­ma­tions d’accès est également con­si­dé­rée comme une méthode par­ti­cu­liè­re­ment sûre. Une clé USB ou une carte à puce peuvent être utilisées à cet effet.

Quels sont les avantages et les in­con­vé­nients du Single Sign-On ?

Le SSO permet d’accéder à plusieurs services et ap­pli­ca­tions sans avoir à se connecter à chaque fois.

Avantages du SSO

Le principal avantage pour les uti­li­sa­teurs est qu’ils n’ont plus à retenir une douzaine de mots de passe. Le SSO nous décharge également de la res­pon­sa­bi­lité de gérer les mots de passe, ce qui explique pourquoi les pro­cé­dures Single Sign-On sont également utilisées comme al­ter­na­tive aux ges­tion­naires de mots de passe. Du fait de cette commodité et du gain de temps associé, ces pro­cé­dures sont ra­pi­de­ment acceptées par l’uti­li­sa­teur aussi bien dans le cadre privé que pro­fes­sion­nel.

Les en­tre­prises in­tro­dui­sant le SSO dans leur activité espèrent avant tout une plus grande pro­duc­ti­vité de leurs col­la­bo­ra­teurs et une baisse des demandes d’as­sis­tance pour perte de mot de passe. Les systèmes in­for­ma­tiques sont ainsi moins sur­char­gés et moins coûteux. Par ailleurs, les spé­cia­listes en in­for­ma­tique ont davantage de facilité à attribuer des comptes aux nouveaux col­la­bo­ra­teurs ou à supprimer les accès d’anciens employés.

Les pro­cé­dures cor­res­pon­dantes per­met­tent de plus de bé­né­fi­cier d’avantages con­si­dé­rables en matière de sécurité des données au sein de l’en­tre­prise. En effet, lorsque les col­la­bo­ra­teurs ont un seul mot de passe à se rappeler, sa com­plexité peut être nettement su­pé­rieure. Il est ainsi possible d’éviter des erreurs typiques dans la sélection d’un mot de passe qui sont souvent la base des attaques de hacking réussies. En outre, comme les données d’accès doivent être saisies dans une seule interface, la fenêtre d’attaque pour les attaques de phishing et de l’homme du milieu s’en trouve nettement réduite. Dans ces cir­cons­tances, l’en­tre­prise peut se permettre de con­cen­trer l’in­té­gra­lité des mesures de sécurité, par exemple les cer­ti­fi­cats SSL, en un seul et même point.

In­con­vé­nients du SSO

Ces avantages doivent être mis en balance avec un certain effort d’im­plé­men­ta­tion ainsi qu’avec des fai­blesses in­hé­rentes à Single Sign-On : en principe, seuls les services supportés par le système SSO peuvent être utilisés. Si le système SSO n’est pas en mesure de s’acquitter de ses tâches, l’accès aux ap­pli­ca­tions associées échoue également. C’est notamment le cas lorsque des comptes de réseaux sociaux sont bloqués par le réseau de bi­blio­thèques et d’ins­ti­tu­tions publiques, de certains lieux de travail pour des raisons de pro­duc­tion ou de pays exerçant une censure active (par ex. la Ré­pu­blique populaire de Chine).

La sécurité du Single Sign-On annoncée doit également être prise avec pré­cau­tion : si un uti­li­sa­teur quitte son poste de travail, un tiers peut en théorie utiliser l’in­ter­valle jusqu’à un single sign-out au­to­ma­tique pour continuer à utiliser des accès déjà accordés. La situation peut également être pro­blé­ma­tique si le « mot de passe maître » pour l’interface SSO tombe aux mains de tiers donnant ainsi à l’attaquant un accès immédiat à tous les services associés. Par ailleurs, il a été prouvé que même les meil­leures pro­cé­dures SSO ne sont pas im­mu­ni­sées contre le phishing.

Le RGPD, qui est en vigueur depuis le 25 mai 2018 et définit les exigences en matière de pro­tec­tion des données à caractère personnel à l’échelle de l’Europe, a également donné la migraine à certains systèmes SSO. Dans tous les cas, il est né­ces­saire d’obtenir une dé­cla­ra­tion de con­sen­te­ment explicite de la part de l’uti­li­sa­teur pour im­plé­men­ter et mettre en œuvre le Single Sign-On con­for­mé­ment à la lé­gis­la­tion. Quoi qu’il en soit, la situation juridique était déjà pro­blé­ma­tique avec la loi « In­for­ma­tique et libertés ». L’un des plus gros points de litige reste par con­sé­quent la collecte de données massive effectuée par les géants du numérique, comme Google et Facebook, les fuites de données pouvant devenir de vé­ri­tables ca­tas­trophes pour la vie privée et les données internes des en­tre­prises.

Au vu de ces risques évidents, il est né­ces­saire d’accorder une attention par­ti­cu­lière à la sécurité des données côté serveur. Idéa­le­ment, les pro­cé­dures Single Sign-On sûres devraient être ren­for­cées avec des moyens efficaces d’au­then­ti­fi­ca­tion à double facteur dont font notamment partie les cartes à puce ou les jetons pouvant générer des TAN.

Études de cas : Facebook vs. Verimi

Les avantages et les in­con­vé­nients de l’au­then­ti­fi­ca­tion unique peuvent être illustrés à l’aide de Facebook. Cette pla­te­forme de réseau social permet à un uti­li­sa­teur de s’inscrire et de se connecter à son compte Facebook sur d’autres sites Internet. Pour cela, un plugin de réseau social est intégré sur la page d’ins­crip­tion et de connexion sous la forme d’un bouton « Se connecter avec Facebook ». C’est une fonction utile pour l’uti­li­sa­teur, mais qui s’ac­com­pagne également d’un in­con­vé­nient puisque Facebook collecte de plus en plus de données à mesure que de nouveaux services et ap­pli­ca­tions sont associés au compte Facebook de cette façon. Une seule cy­be­rat­taque réussie suffit alors pour avoir accès à l’ensemble des données.

Facebook choisit également de partager ces in­for­ma­tions, qui étaient ex­clu­si­ve­ment destinées à la pla­te­forme de réseau social, avec les services en question. Les données con­cer­nées sont aussi bien des données publiques, comme le nom et la photo de profil, mais aussi des données non publiques, telles que l’âge, le lieu d’ha­bi­ta­tion ou le statut de la relation d’une personne. Même si Facebook indique de façon aussi trans­pa­rente que possible quelles données sont trans­mises, les uti­li­sa­teurs n’ont souvent d’autre choix que d’accepter cette trans­mis­sion pour utiliser certains services. À l’inverse, Facebook reçoit également des données des services connectés en question. La pla­te­forme peut ainsi compléter ses profils d’uti­li­sa­teur et ainsi afficher des pu­bli­ci­tés encore plus per­son­na­li­sées.

Ce constat sur Facebook est également ap­pli­cable dans une certaine mesure aux autres pres­ta­taires en ligne, notamment Google ou Amazon. En avril 2018, cette pro­blé­ma­tique a poussé plusieurs en­tre­prises al­le­mandes (dont Allianz, Deutsche Bank, Die Telekom et Axel Springer) à faire équipe pour publier un produit con­cur­rent destiné au marché européen : Verimi. Ce nouveau four­nis­seur d’identité SSO devrait assurer un niveau de pro­tec­tion des données et une trans­pa­rence plus élevés et peut ainsi être utilisé du­ra­ble­ment dans les secteurs bancaire et ad­mi­nis­tra­tif. Ce projet est basé sur le règlement général sur la pro­tec­tion des données per­son­nelles, ainsi que sur un en­re­gis­tre­ment chiffré des données à caractère personnel dans des centres de calcul ex­clu­si­ve­ment européens. La mesure dans laquelle le projet par­vien­dra à s’imposer dépend toutefois du nombre de par­te­naires qui l’in­té­gre­ront à l’avenir dans leurs sites Internet et leurs ap­pli­ca­tions.

En résumé : le SSO – oui ou non ?

Si l’on effectue une recherche Internet sur le Single Sign-On, on trouve re­la­ti­ve­ment peu de points négatifs à cette procédure d’au­then­ti­fi­ca­tion pratique. Au lieu de cela, le SSO est plutôt considéré depuis des années comme une véritable ré­vé­la­tion pour les postes de travail nu­mé­riques en termes de commodité et de sécurité des données. Le Cloud-Access-Security-Broker américain Bitglass fait par exemple l’éloge de l’uti­li­sa­tion intensive des services Cloud dans les en­tre­prises, mais déplore également la faible uti­li­sa­tion des pro­cé­dures Single Sign-On. Selon lui, l’uti­li­sa­tion de solutions d’accès aux services et aux ap­pli­ca­tions qui sont en con­cur­rence in­vo­lon­taire ne per­met­trait pas d’exploiter plei­ne­ment le potentiel de la nu­mé­ri­sa­tion.

Aller au menu principal