D'ici 2021, le gouvernement britannique comptait environ 121 solutions de single sign-on distinctes, ce qui démontre pourquoi le SSO dépasse la simple fonction de confort. Le SSO correspond à la consolidation de l'identité fédérée : il centralise l'authentification via un fournisseur d'identités de confiance, tout en laissant à chaque application le contrôle des autorisations accordées à un utilisateur authentifié.
Vous reconnaissez peut-être ce problème dans votre quotidien professionnel. Un collaborateur a besoin de son e-mail, d'une application cloud, d'un système de gestion immobilière, du WiFi interne et d'un portail d'administration. Chaque service possède ses propres identifiants, sa politique de mot de passe et son responsable de compte. Lors d'une arrivée, d'un changement de rôle ou d'un départ, les administrateurs doivent mettre à jour plusieurs systèmes, et les utilisateurs doivent se rappeler quels identifiants appartiennent à quel service.
C'est la raison pratique pour laquelle les organisations recherchent une explication du SSO. La question n'est pas seulement de savoir comment réduire le nombre d'écrans de connexion. Il s'agit de savoir comment créer un plan de contrôle des identités fiable sans affaiblir les autorisations au niveau de l'application ni introduire une cible centrale plus dangereuse.
Pourquoi la fragmentation des identités crée de véritables problèmes d'accès
L'expérience du gouvernement britannique constitue un point de départ utile. Une évaluation des normes de service GOV.UK de 2021 a estimé que l'administration centrale disposait d'environ 121 solutions SSO différentes parce que les équipes de service avaient conçu des systèmes d'authentification séparés au lieu d'utiliser une plateforme d'identité partagée à l'échelle du gouvernement. Les personnes utilisant plusieurs services publics pouvaient donc détenir plusieurs jeux d'identifiants et ne pas savoir quel compte était requis pour une transaction particulière. (Revue de l'authentification et de l'identité numérique du gouvernement britannique)
La leçon n'est pas que les systèmes gouvernementaux sont exceptionnellement complexes. Les grandes entreprises, les établissements de santé, les groupes hôteliers, les gestionnaires immobiliers et les réseaux du secteur public sont confrontés au même schéma. Chaque application peut créer un silo d'identités, et chaque silo peut développer ses propres règles de mot de passe, procédures de récupération, modèles de groupes et processus de départ.
L'authentification et l'autorisation sont deux rôles distincts
L'authentification répond à la question « Qui êtes-vous ? ». L'autorisation répond à la question « À quoi pouvez-vous accéder ici ? ». Le SSO consolide la première question grâce à un fournisseur d'identité de confiance. L'application cible décide toujours si cette identité peut consulter des enregistrements, administrer un système, rejoindre un segment de réseau ou utiliser une fonctionnalité particulière.
Voici un modèle conceptuel utile :
Utilisateur
|
| s'authentifie une fois
v
Fournisseur d'identités
|
| envoie des informations d'identité approuvées
v
Application ou réseau
|
| applique les autorisations locales
v
Session autorisée
Cette distinction est essentielle lors des processus d'arrivée, de changement de poste ou de départ. Une identité centrale peut être désactivée lorsqu'une personne quitte l'entreprise, tandis que chaque service connecté nécessite toujours un modèle d'autorisation clair et un moyen fiable de supprimer les droits d'accès.
Règle pratique : Considérez le SSO comme un moyen de contrôler l'identité de manière centralisée, et non comme un substitut aux autorisations d'application.
Le même principe s'applique lors de la conception d'un déploiement filaire et sans fil. L'accès au réseau fait partie du patrimoine d'identités, de sorte que les équipes doivent décider quels groupes d'annuaire peuvent accéder à quels rôles réseau, plutôt que d'associer l'accès à un mot de passe partagé.
Pour le WiFi du personnel et l'accès basé sur l'identité, les réseaux basés sur l'identité de Purple démontrent comment la politique réseau peut être liée à une identité individuelle plutôt qu'à un identifiant partagé. Le résultat est une relation plus claire entre une personne, son statut dans l'annuaire et les accès qui lui sont accordés.
Comment fonctionne le Single Sign-On dans la fédération d'entreprise
Dans une fédération d'entreprises, un fournisseur d'identité, une partie de confiance et un message d'identité signé accomplissent des tâches distinctes. Le fournisseur d'identité authentifie l'utilisateur, tandis que la partie de confiance, comme une application ou un service réseau, vérifie les informations d'identité transmises.
L'authentification peut utiliser un mot de passe, une authentification multifacteur, des conditions d'appareil ou une autre méthode approuvée. Le fournisseur émet ensuite une assertion signée ou un jeton pour le service demandé. Le service valide ce message et crée sa propre session, de sorte que les identifiants restent auprès du fournisseur d'identité.
Le flux de fédération
- L'utilisateur demande un service. Il ouvre une application, un portail d'administration ou un service réseau protégé.
- Le service vérifie l'existence d'une session. S'il n'y en a pas, il redirige l'utilisateur vers le fournisseur d'identités.
- Le fournisseur d'identités authentifie l'utilisateur. Il applique les contrôles configurés, tels que le MFA ou l'accès conditionnel.
- Le fournisseur d'identités émet un message signé. L'intégration utilise généralement une assertion SAML ou un jeton OpenID Connect.
- Le service valide le message. Il vérifie l'émetteur, la signature, le public cible, l'expiration et les revendications associées.
- L'application crée sa propre session. Elle associe l'identité vérifiée aux autorisations locales et enregistre l'événement d'authentification.
La validation protège la relation de confiance. Le NCSC (National Cyber Security Centre du Royaume-Uni) recommande que les assertions SAML reçues sur des réseaux non approuvés soient vérifiées par rapport à l'autorité de certification attendue. Une assertion non vérifiée peut offrir une voie de prise de contrôle de compte via une connexion établie avec un fournisseur d'identité de confiance. (Recommandations du NCSC sur la gestion des identités et des accès)
Une vérification d'identité valide accorde une identité authentifiée, mais pas l'ensemble des autorisations dans le service cible. L'application ne doit consommer que les assertions requises pour l'autorisation, puis appliquer ses propres règles de rôles et de ressources. Cette séparation permet également au même modèle de fédération de prendre en charge les applications du personnel, les portails d'administration et les services réseau basés sur l'identité.
SAML, OIDC et OAuth en contexte d'entreprise
Une fois le modèle de fédération éclairci, le choix du protocole devient plus simple. SAML et OpenID Connect sont des standards courants pour le SSO d'entreprise, tandis qu'OAuth est principalement un cadre d'autorisation pour l'accès délégué aux API. Confondre OAuth avec l'authentification peut amener les équipes à concevoir un flux d'identité qui ne répond pas aux exigences de sécurité requises.
| Norme | Rôle pratique | Usage type |
|---|---|---|
| SAML | Échange des assertions d'identité signées | Entreprises établies et applications basées sur navigateur |
| OpenID Connect | Ajoute une couche d'identité à l'aide de jetons | SaaS modernes, services web et orientés mobile |
| OAuth | Délègue l'accès à des ressources protégées | Accès API pour le compte d'un utilisateur ou d'un service |
SAML apparaît souvent dans les logiciels d'entreprise éprouvés car il utilise un modèle de fédération par navigateur bien établi. OIDC est généralement plus naturel pour les services modernes conçus autour de JSON, REST et des interactions basées sur des jetons. Le bon choix dépend de ce que l'application prend en charge et de la manière dont le service valide les informations d'identité.
Ce que le service doit vérifier
Quel que soit le standard, la partie de confiance doit valider les éléments d'identité reçus avant de créer une session. Les vérifications fondamentales comprennent :
- Émetteur : Confirmez que le message provient du fournisseur d'identité attendu.
- Signature : Vérifiez que le message a été signé par la clé ou le certificat de confiance.
- Audience : Vérifiez que le message était bien destiné à ce service.
- Expiration : Rejetez les assertions ou jetons obsolètes.
- Attributs (Claims) : Utilisez uniquement les informations d'identité et de groupe pertinentes et validées.
Le fournisseur d'identités peut centraliser des politiques telles que le MFA, l'accès conditionnel, l'interdiction de mots de passe et l'appartenance à des groupes. L'application reçoit ensuite les revendications nécessaires à sa propre décision d'autorisation, plutôt que de maintenir une copie complète du processus d'authentification de l'utilisateur.
Cette séparation est utile lors de l'intégration de plateformes telles que Microsoft Entra ID, Okta ou Google Workspace. Le fournisseur gère la politique d'authentification, tandis que l'application connectée reste responsable de son modèle d'accès et des contrôles de session. Pour les opérateurs réseau qui évaluent l'intégration Okta pour un accès basé sur RADIUS, le même principe s'applique : la validation de l'identité et l'autorisation réseau doivent fonctionner ensemble, mais elles ne constituent pas le même contrôle.
Le risque de concentration introduit par le SSO
Un seul compte de fournisseur d'identités compromis peut ouvrir accès à plusieurs services connectés à la fois. Le SSO réduit la dispersion des mots de passe, tout en concentrant la confiance dans le fournisseur d'identités, ce qui en fait un plan de contrôle à haute valeur ajoutée. Les organisations doivent donc évaluer la manière dont la fédération affecte leur rayon d'impact et leurs options de récupération. Les recommandations du NCSC sur le choix des méthodes d'authentification mettent en évidence cette concentration de confiance comme un risque nécessitant une évaluation méthodique.
Le SSO consolide les événements de connexion. La résistance au phishing, la confiance accordée aux appareils et l'accès basé sur le moindre privilège doivent provenir des contrôles intégrés à l'architecture de fédération. Une conception solide protège le fournisseur, les sessions qu'il crée et les processus de récupération qui permettent de restaurer l'accès.
Construire des couches de protection autour du fournisseur
Les contrôles doivent couvrir la connexion de routine ainsi que les parcours moins visibles utilisés lors de la récupération de compte :
- MFA renforcé pour les utilisateurs privilégiés : Utilisez des méthodes résistantes au hameçonnage lorsque l'environnement le permet, en particulier pour les administrateurs.
- Accès conditionnel : Évaluez l'état de l'appareil, l'emplacement, le risque de la session et d'autres signaux disponibles avant d'accorder l'accès.
- Identités d'administrateur séparées : Séparez l'administration privilégiée des activités quotidiennes ordinaires.
- Surveillance de l'authentification : Enquêtez sur les déplacements impossibles, les indicateurs de rejeu de jetons, les échecs répétés et les élévations de privilèges inattendues.
- Protection du recouvrement : Traitez les réinitialisations du centre d'assistance et les comptes d'urgence comme des opérations d'identité sensibles, soumises à approbation et surveillance.
Le NCSC recommande de combiner le SSO d'entreprise avec une authentification forte des utilisateurs et des appareils, y compris l'authentification multifacteur (MFA) ou l'accès conditionnel. Il recommande également le SSO pour le SaaS, car des contrôles centralisés rendent la gestion des utilisateurs et des groupes plus cohérente et empêchent la synchronisation des identifiants dans chaque application. Son principe de sécurité cloud sur l'identité et l'authentification détaille cette approche.
Le SSO réduit le nombre d'identifiants que vous devez gérer. Il exige une protection renforcée de l'identifiant et de la session qui régissent les services connectés.
Les équipes réseau doivent séparer l'identité des collaborateurs de celle des invités. Une fédération pour le personnel permet de prendre en charge le principe du moindre privilège et une révocation rapide. L'authentification des invités ne doit pas hériter des privilèges de l'annuaire des employés sous prétexte que les deux flux utilisent un Captive Portal ou une infrastructure sans fil.
WiFi sans mot de passe et accès réseau basé sur l'annuaire
Un membre du personnel qui se connecte au WiFi ne devrait pas avoir besoin d'un mot de passe partagé qui reste valide après son départ. Une architecture reposant sur un annuaire commence par une authentification via le fournisseur d'identité de l'organisation, puis associe l'identité ou le groupe vérifié à un rôle réseau. Le service sans fil applique ainsi les mêmes décisions d'emploi et d'accès que celles utilisées ailleurs, plutôt que de maintenir une liste distincte de mots de passe WiFi.
Purple prend en charge ce modèle pour le WiFi d'entreprise grâce à des intégrations avec Microsoft Entra ID, Google Workspace et Okta. Son approche de WiFi sans mot de passe évite les identifiants partagés et la gestion RADIUS sur site. Les modifications apportées à l'annuaire peuvent déclencher une attribution ou une révocation d'accès. L'appartenance à un groupe d'un membre du personnel détermine son accès au réseau, tandis que la désactivation du compte d'un partant dans l'annuaire permet de supprimer cet accès sans attendre que quelqu'un modifie un mot de passe commun.
Appliquer les contrôles de fédération au réseau
Le fournisseur d'identité, la politique réseau et la surveillance doivent être alignés sur la même décision d'accès. Associez les groupes de l'annuaire à des rôles réseau distincts, de sorte que le personnel, les sous-traitants et les administrateurs ne reçoivent pas des accès identiques par défaut. Conservez des durées de vie courtes pour les assertions ou les jetons, afin de limiter l'utilité des éléments d'identité obsolètes. Exigez la MFA au niveau du fournisseur d'identité, car un SSO sans fil ne devient pas de la MFA du simple fait d'utiliser le SSO.
Enregistrez les événements d'authentification réussis et échoués, et associez chaque décision d'identité à l'autorisation réseau qui en découle. Testez le renouvellement des certificats avant leur expiration, car les échecs de confiance de fédération peuvent interrompre un accès WiFi par ailleurs parfaitement fonctionnel.
Les sites multi-locataires nécessitent une séparation distincte. Les résidences, les logements étudiants, les hôtels et les sites à usage mixte peuvent offrir un accès simple aux résidents ou aux invités tout en isolant le trafic des locataires et les systèmes du personnel. L'iPSK peut prendre en charge les équipements hérités, tandis que le SSO dédié aux collaborateurs fournit un parcours d'identité distinct pour le personnel.
Le WiFi invité implique également des choix concernant le consentement, la conservation et les profils clients. Ce guide sur les données clients pour les établissements offre une référence utile en parallèle de la conception du réseau, tandis que Purple associe l'authentification basée sur l'identité à l'expérience d'accès sans fil.
Résultats mesurables pour les entreprises et établissements
Un cas d'usage économique pratique du SSO commence par les identifiants qu'une organisation n'a plus besoin d'administrer. Une enquête menée en avril 2024 par l'Institution of Engineering and Technology auprès de 2 000 résidents du Royaume-Uni âgés de 16 ans et plus a révélé que seuls 20 % d'entre eux pouvaient identifier correctement un mot de passe sécurisé. La même étude indique qu'un cinquième réutilisait un mot de passe sur plusieurs sites web ou appareils, tandis que 21 % utilisaient une date importante et 20 % le nom d'un animal de compagnie. Elle a également révélé que 38 % pensaient que remplacer des lettres par des chiffres améliorait la sécurité d'un mot de passe, 65 % pensaient que les mots de passe ne devaient jamais être écrits, et 77 % pensaient que des modifications fréquentes de mot de passe augmentaient la sécurité. (Enquête IET sur la sécurité des mots de passe)
Ces constatations montrent les limites d'inciter les utilisateurs à créer et mémoriser des identifiants distincts pour chaque application et réseau. L'identité centralisée modifie l'endroit où l'organisation applique ses contrôles et la rapidité avec laquelle les administrateurs peuvent agir, même si le hameçonnage et la compromission de compte restent des risques bien réels.
Pour un opérateur, les résultats sont concrets :
- Moins d'identifiants non gérés : Les utilisateurs créent, mémorisent et réutilisent moins de mots de passe d'application distincts.
- Politique cohérente : Le fournisseur d'identités peut appliquer le MFA, l'accès conditionnel et les restrictions de mot de passe sur l'ensemble des services connectés.
- Révocation plus rapide : La désactivation d'une identité organisationnelle peut devenir l'action centrale de suppression d'accès, à condition que les services connectés traitent correctement les changements de cycle de vie.
- Pistes d'audit plus claires : Les journaux peuvent lier l'identité d'une personne aux décisions d'authentification et d'autorisation réseau.
- Moins d'administration doublonnée : Les équipes maintiennent la politique d'identité de manière centralisée au lieu de recréer des contrôles équivalents dans chaque service.
La valeur ajoutée va bien au-delà de la simple réduction des invites de connexion. Un prestataire de soins de santé peut attribuer des accès par rôle, un groupe hôtelier peut séparer les services du personnel et des clients, et un gestionnaire immobilier peut maintenir une propriété plus claire des habilitations des locataires et des employés. Dans chaque cas, le résultat mesurable est un parc d'identifiants réduit, un traitement des départs plus fiable et une preuve plus solide des personnes ayant obtenu l'accès à une application ou à un rôle réseau.
Mettre en œuvre le SSO sans créer de nouveaux risques
Un déploiement sécurisé commence par le modèle d'identité, et non par le bouton de connexion. Choisissez SAML ou OIDC lorsqu'ils sont adaptés à l'application, plutôt que de copier des mots de passe dans une application ou une plateforme réseau. Établissez le fournisseur d'identités comme l'autorité d'authentification, puis veillez à ce que chaque service connecté valide l'émetteur, la signature, le public cible, l'expiration et les assertions avant de créer une session.
Utiliser une liste de contrôle opérationnelle
- Commencez par des groupes faisant autorité : Attribuez les accès à partir de groupes d'annuaires détenus par la bonne équipe métier ou informatique.
- Définissez des règles de mobilité interne : Un changement de rôle doit supprimer les anciens droits et ajouter les nouveaux.
- Gérez les départs de manière centralisée : Désactivez l'identité organisationnelle et vérifiez que les applications connectées et les rôles réseau répondent correctement.
- Protégez les accès d'urgence : Séparez les comptes de secours de l'administration ordinaire, surveillez-les de près et testez leur procédure de récupération.
- Séparez le personnel et les visiteurs : Le SSO des collaborateurs peut prendre en charge l'accès à moindre privilège et la révocation. L'authentification des visiteurs ne doit pas hériter des autorisations des employés.
- Testez les modifications de confiance : Validez le renouvellement des certificats, l'expiration des jetons, la fin de session et les pannes de fournisseur avant la mise en production.
- Révisez la surveillance : Confirmez que les événements d'authentification, les actions administratives et les décisions d'autorisation réseau sont disponibles pour analyse.
Un site peut également avoir besoin de prendre en charge plusieurs fournisseurs réseau plutôt que de remplacer son parc sans fil existant. Purple est conçu pour fonctionner avec Meraki, Aruba, Ruckus, Mist et UniFi, et son modèle de déploiement annoncé se mesure en semaines plutôt qu'en mois. Traitez ces capacités comme des considérations de mise en œuvre et non comme des substituts à une révision d'architecture. Pour une vision plus large de la façon dont les fournisseurs de technologies décrivent les garanties de sécurité, la page confiance et contrôles de AdManage.ai offre un point de comparaison utile.
La décision centrale consiste à déterminer si l'organisation peut expliquer, pour chaque service connecté, qui authentifie l'utilisateur, quelles assertions sont approuvées, comment les autorisations sont attribuées et ce qui se produit lorsque l'identité change. Le SSO est une couche au sein d'un programme de gestion des identités et des accès. Il ne remplace pas le MFA, l'accès conditionnel, la surveillance des authentifications, les contrôles de récupération ou la gouvernance du cycle de vie.
Purple associe l'identité des collaborateurs à un accès WiFi sans mot de passe, à des rôles réseau basés sur les annuaires et à un accès invité distinct, en prenant en charge les intégrations avec Microsoft Entra ID, Google Workspace et Okta. Visitez Purple pour évaluer comment son modèle de réseau basé sur l'identité s'intègre à votre environnement sans fil actuel et à votre déploiement SSO.
