Passer au contenu principal

Comment activer l'authentification unique (Single Sign On)

30 September 2026
21 min de lecture
How to Enable Single Sign On

La matinée du lundi commence avant l'arrivée des clients. Lors du changement d'équipe d'un hôtel, l'équipe de nuit part, l'équipe de jour arrive et trois ordinateurs portables du personnel se retrouvent bloqués sur le Captive Portal parce que quelqu'un a changé le mot de passe WiFi partagé et a oublié de mettre à jour le tableau blanc de l'arrière-boutique. Un employé cherche un ancien ticket, un autre interroge un superviseur, et le troisième abandonne pour utiliser un point d'accès personnel.

Ce n'est pas un problème de couverture WiFi. C'est un problème d'identité. Le single sign-on, ou SSO, permet au personnel de s'authentifier avec son identité professionnelle existante et d'accéder au réseau du personnel sans avoir à saisir un autre mot de passe partagé. Ce guide explique comment activer le single sign-on sur un SSID destiné au personnel géré par Purple, choisir le bon fournisseur d'identité, configurer la fédération, tester le résultat et sécuriser le déploiement en cas de problème.

Pourquoi les réseaux du personnel ont besoin du Single Sign-On

Les clés pré-partagées partagées échouent de manière prévisible. Le personnel les écrit sur des post-it, les colle dans les outils de gestion des tickets, les répète à la radio et continue de les utiliser après avoir quitté l'entreprise. Un établissement peut modifier la clé pour résoudre un problème d'accès, pour se retrouver face à une nouvelle file d'attente de demandes de connexion au changement d'équipe suivant.

Le coût opérationnel se manifeste par de petites interruptions. Un réceptionniste attend une réinitialisation pendant l'enregistrement des clients, une infirmière perd du temps à reconnecter un poste de travail, et un superviseur de magasin appelle le support technique parce qu'un appareil portable ne parvient pas à se connecter au SSID du personnel. Ces retards sont difficiles à mesurer individuellement, mais ils se répètent chaque fois que le réseau traite l'ensemble du personnel comme un compte unique.

Le SSO modifie l'unité d'accès du mot de passe partagé à l'identité individuelle. Un employé se connecte via le fournisseur d'identité de l'organisation, et le réseau applique la politique d'accès associée à cette personne ou à son groupe. Lorsque l'employé change de service, son appartenance à un groupe peut changer avec lui. Lorsqu'il s'en va, la désactivation du compte d'annuaire peut supprimer l'accès sans modifier un mot de passe utilisé par tous les autres.

Pour les organismes du secteur public britannique, le problème de fragmentation est déjà visible à l'échelle nationale. Les recommandations d'authentification et d'identité numérique de GOV.UK ont signalé environ 121 solutions d'authentification unique (SSO) au sein du gouvernement en 2021, ainsi qu'environ 191 méthodes de création de compte et 44 méthodes de connexion. GOV.UK One Login a été créé comme une couche d'authentification commune, et cette même mise à jour indiquait qu'il avait été utilisé par plus de 1,5 million de personnes pour prouver leur identité en juillet 2023, tandis que son application compagnon avait été téléchargée 2 millions de fois.

Ce que le SSID du personnel doit imposer

Un réseau pour le personnel géré par Purple offre à l'établissement un espace pratique pour connecter l'identité professionnelle à l'accès sans fil. L'approche de gestion de réseau basée sur l'identité sépare l'accès du personnel de l'accès des invités et permet à la politique réseau de suivre l'identité authentifiée plutôt qu'un identifiant affiché sur un tableau d'affichage.

Cela importe pour bien plus que la simple commodité :

  • Passage de relais : Les employés peuvent utiliser leurs propres identifiants professionnels au lieu de demander une clé à l'équipe précédente.
  • Départ de l'entreprise : La désactivation dans l'annuaire peut supprimer l'accès sans obliger chaque collègue à se reconnecter.
  • Auditabilité : Les événements réseau peuvent être associés à des personnes ou à des groupes plutôt qu'à une clé PSK anonyme.
  • Segmentation : Les groupes peuvent être associés aux SSIDs du personnel, aux VLANs ou aux politiques de Captive Portal adaptées à leur rôle.
  • Règles de conformité : Les identifiants sensibles sont moins susceptibles d'apparaître dans les tickets du support technique ou dans les documents partagés.

Le SSO ne supprime pas la nécessité d'une conception sans fil résiliente, de la gestion des appareils ou de contrôles d'accès judicieux. Il élimine le piège des identifiants partagés, ce qui est généralement le chemin le plus court pour rendre le WiFi du personnel gérable.

Flux d'authentification qui alimentent le SSO du personnel

Le flux que vous choisissez dépend de l'endroit où l'authentification a lieu et de ce que votre équipement réseau comprend. Le fournisseur d'identité peut émettre l'assertion, mais un point d'accès a toujours besoin d'un mécanisme pour décider si un appareil peut rejoindre le SSID.

Le protocole SAML 2.0 est la solution standard des entreprises. Entra ID et Okta peuvent émettre une assertion signée contenant un identifiant stable, une adresse e-mail et des informations de groupe. Le fournisseur de services valide cette assertion et crée la session authentifiée. SAML convient aux organisations qui l'utilisent déjà pour les applications SaaS et qui souhaitent qu'un seul annuaire reste la source unique de vérité.

OpenID Connect, ou OIDC, utilise des jetons modernes basés sur JSON. Il s'adapte particulièrement bien à Google Workspace et aux applications plus récentes, et sa structure de jeton peut être plus facile à inspecter lors du dépannage. Les plateformes sans fil plus anciennes ne gèrent pas toujours directement OIDC, le flux peut donc nécessiter un courtier ou une passerelle avant que le point d'accès ne puisse appliquer la décision.

Le protocole RADIUS reste la passerelle entre l'identité et le WiFi d'entreprise. Un authentificateur 802.1X, généralement le point d'accès ou le contrôleur sans fil, envoie des requêtes d'authentification à un service RADIUS. Ce service peut être Cloud RADIUS, Microsoft NPS, un serveur RADIUS sur site ou un fournisseur géré. Même lorsque l'utilisateur commence sur un fournisseur d'identité SAML, RADIUS se situe généralement entre le système d'identité et l'infrastructure sans fil.

L'authentification par certificat utilise un certificat machine, et parfois un certificat utilisateur, pour établir une connexion de haute confiance. Les hôpitaux, les laboratoires et les environnements de trading peuvent préférer cette approche pour les appareils gérés car le certificat est délivré par la politique de l'appareil plutôt que d'être saisi par un employé. Cela demande plus de préparation, notamment en ce qui concerne l'enrôlement, le renouvellement et la révocation des certificats, mais cela réduit la dépendance à l'égard de la saisie interactive des mots de passe.

Aperçu des flux d'authentification SSO du personnel

Flux Idéal pour IdP classique Expérience utilisateur du personnel
SAML 2.0 Fédération d'entreprise et accès basé sur les groupes Entra ID ou Okta Connexion via le navigateur, puis session authentifiée
OIDC Applications modernes et intégrations basées sur JSON Google Workspace ou un IdP compatible OIDC Authentification web familière avec fédération basée sur des jetons
RADIUS Accès WiFi 802.1X et équipements réseau existants Cloud RADIUS, NPS ou un fournisseur managé L'appareil rejoint le SSID après l'authentification réseau
Authentification par certificat Appareils managés et environnements à haut niveau de confiance PKI d'entreprise avec intégration d'annuaire Généralement transparente après l'enrôlement du certificat

Un SSID destiné au personnel de Purple permet de relier ces différentes couches. L'IdP établit l'identité, RADIUS gère l'authentification réseau si nécessaire, le point d'accès applique le résultat et le tableau de bord Purple offre aux administrateurs une vue opérationnelle de l'événement de connexion. Si la MFA fait partie de votre architecture, traitez-la comme un contrôle d'identité plutôt que comme un substitut à la segmentation réseau. La présentation de la MFA par Networking2000 constitue une ressource utile pour déterminer comment un deuxième facteur s'intègre au flux SSO.

Règle pratique : Utilisez SAML lorsque vos applications d'entreprise en dépendent déjà, OIDC pour les intégrations web modernes, RADIUS pour l'application de la norme 802.1X, et des certificats lorsque l'appareil lui-même doit porter une preuve d'identité forte.

Choisir le bon fournisseur d'identité

Le bon fournisseur d'identité est généralement celui que votre organisation exploite déjà de manière efficace. Faire un choix basé uniquement sur une liste de fonctionnalités peut mener à une architecture technique élégante que les gestionnaires de site ne peuvent pas administrer et que le centre d'assistance ne comprend pas.

Microsoft Entra ID est une solution naturelle pour les parcs construits autour de Microsoft 365. L'accès conditionnel, les groupes d'annuaires, le contexte de l'appareil et les compétences existantes des administrateurs peuvent tous soutenir la politique réseau du personnel. Les hôpitaux équipés de terminaux gérés et de parcs régionaux Microsoft préfèrent souvent conserver les décisions d'authentification au sein du même plan de contrôle que leurs autres services d'entreprise.

Google Workspace fonctionne parfaitement lorsque l'annuaire se trouve déjà dans Google et que l'entreprise souhaite éviter d'introduire une autre plateforme d'identité. Les hôtels, les détaillants et les petits groupes de restauration qui se sont standardisés sur Google trouveront son administration familière et le cycle de vie de ses utilisateurs simple.

Okta convient généralement aux organisations qui ont besoin d'une large couche de fédération à travers des applications évolutives, des entreprises acquises ou de multiples annuaires. Le SCIM, les règles de groupe détaillées et un échange de métadonnées SAML propre peuvent s'avérer plus importants qu'une longue liste de fonctionnalités inutilisées lorsqu'un groupe hôtelier se développe ou intègre des parcs distincts.

Une configuration locale combinant Active Directory et NPS a toujours sa place. Elle est pertinente lorsque le réseau sans fil dépend déjà de la norme 802.1X, que l'annuaire est local, que la disponibilité du réseau WAN est limitée, ou que l'organisation possède de solides compétences en infrastructure Windows. Cela implique également une responsabilité accrue en matière de correctifs, de gestion des certificats, de redondance et de surveillance.

Matrice de décision IdP pour le SSO du personnel Purple

IdP Point fort Points de vigilance Lieu typique
Entra ID Accès conditionnel, alignement Microsoft 365, gestion de groupe mature La complexité des licences et des politiques peut nécessiter une administration spécialisée Hôpital ou parc multi-régions
Google Workspace Annuaire Google existant, administration familière, alignement simple des effectifs L'authentification réseau peut nécessiter une couche RADIUS ou de fédération supplémentaire Hôtel ou groupe de vente au détail utilisant déjà Google
Okta Fédération flexible, SCIM, groupes granulaires, prise en charge des environnements mixtes La structure contractuelle et les coûts par poste nécessitent un examen attentif Groupe hôtelier en forte croissance
Active Directory plus NPS Idéal pour les environnements 802.1X établis et Windows locaux Plus d'infrastructures à exploiter, à sécuriser et à rendre hautement disponibles Site disposant d'une infrastructure informatique sur site mature

La politique d'accès est le domaine où le choix devient concret. Vérifiez si le fournisseur peut exposer des revendications de groupe fiables, si ces revendications peuvent être associées à des rôles de personnel ou à des VLANs, comment la MFA est appliquée, et à quelle vitesse un compte désactivé cesse de s'authentifier. Évaluez également si un responsable de site non-informaticien peut comprendre suffisamment les écrans d'administration pour gérer un nouvel arrivant ou un transfert de service.

Pour une vision plus large de l'impact de la gestion des identités et des accès sur les systèmes d'entreprise, les ressources IAM de Kushan Business Solutions offrent un contexte utile au-delà de l'authentification sans fil. La recommandation pratique reste simple : commencez par la réalité de votre annuaire, et non par la brochure des fonctionnalités du fournisseur.

Purple consomme des métadonnées de fédération standard, de sorte qu'un changement d'IdP ne nécessite pas une reconstruction du réseau sans fil. La migration exacte nécessite toujours des tests, mais le remplacement de la connexion d'identité est normalement un exercice de configuration contrôlé. Gardez la politique réseau, la dénomination des groupes et le chemin de repli documentés avant de changer de fournisseur. Pour les équipes qui ont besoin d'une couche RADIUS gérée, examinez les fournisseurs Cloud RADIUS disponibles en parallèle avec la plateforme d'identité plutôt que de traiter RADIUS comme une réflexion après coup.

Configuration du SSO sur la console Purple et l'annuaire

La fédération réussit de manière plus fiable lorsque le fournisseur d'identité est préparé avant la création de la connexion Purple. L'erreur courante consiste à ouvrir les deux consoles et à copier les valeurs de l'une à l'autre sans avoir préalablement décidé quel identifiant, quels noms de revendications et quel certificat feront autorité.

Préparer l'application d'entreprise

Créez l'application dans Microsoft Entra ID, Okta ou Google Workspace. Choisissez SAML 2.0 lorsque l'intégration du réseau du personnel nécessite une assertion, puis enregistrez les valeurs du fournisseur de services fournies par Purple :

  1. Copiez l'URL ACS, également appelée URL du service client d'assertion, dans le champ de réponse ou d'URL de connexion de l'IdP.
  2. Copiez l'Entity ID dans le champ d'identifiant ou d'audience de l'IdP.
  3. Définissez le NameID sur l'identifiant d'employé stable attendu par l'intégration. L'adresse e-mail est souvent pratique, mais ne changez pas de format en cours de déploiement.
  4. Transmettez les attributs requis, généralement l'e-mail, le nom d'affichage et le groupe.
  5. Attribuez un groupe pilote plutôt que l'ensemble du personnel.
  6. Téléchargez les métadonnées de fédération et le certificat de signature depuis l'IdP.

Pour l'OIDC, enregistrez l'émetteur, l'identifiant client, le point de terminaison d'autorisation, le point de terminaison de jeton et le secret client fournis par l'intégration. Conservez les secrets dans le gestionnaire de mots de passe approuvé, et non dans un ticket ou une feuille de calcul partagée.

Ajouter le fournisseur dans Purple

Ouvrez le portail Purple et suivez Authentication > Identity Providers > Add. Sélectionnez SAML 2.0 ou OIDC, selon la conception, puis importez les métadonnées de l'IdP ou saisissez manuellement les points de terminaison demandés. Associez le nouveau fournisseur d'identité au domaine RADIUS du personnel ou au profil de Captive Portal, et sélectionnez les mappages groupe-politique avant d'enregistrer.

Screenshot from https://console.purple.ai/auth/identity-providers/new

Utilisez la tolérance de dérive d'horloge par défaut documentée de la console, à moins que votre politique de sécurité n'exige une valeur plus stricte. N'inventez pas une tolérance locale pour faire passer une assertion défaillante. Corrigez plutôt la source temporelle sur l'IdP, le service RADIUS et l'équipement réseau.

Ordre de configuration : Créez et attribuez l'application IdP, mappez les revendications, exportez les métadonnées, importez-les dans Purple, liez le profil du personnel, testez avec un compte pilote, puis activez la politique de production.

Deux erreurs représentent une grande partie des premiers essais infructueux. La première est une non-correspondance entre l'URI de l'identifiant dans l'IdP et l'Entity ID attendu par Purple. La seconde est l'importation de métadonnées qui ne sont pas signées ou dont la signature ne peut pas être validée après une actualisation. Vérifiez la chaîne exacte, y compris la casse et les caractères de fin, et établissez comment la rotation des certificats sera approuvée avant la production.

Si le site dépend toujours d'une infrastructure de domaine Windows, séparez la conception de l'annuaire de la conception de la fédération. Un guide tel que l'explication de Monro Cloud sur la promotion d'un contrôleur de domaine peut aider à clarifier la tâche Active Directory sous-jacente, mais il ne remplace pas la configuration SSO ou les tests réseau.

Enfin, vérifiez les options d'intégration pertinentes dans la bibliothèque de connecteurs de Purple. Limitez la portée du premier changement. Un seul groupe de collaborateurs, une seule politique de SSID, un site de test désigné et une solution de secours documentée facilitent grandement le dépannage par rapport à une migration simultanée à l'échelle de tout le parc.

Tester et vérifier le flux de connexion du personnel

Ne testez pas uniquement depuis le navigateur déjà authentifié d'un administrateur. Les sessions IdP en cache peuvent donner l'impression qu'une fédération défectueuse fonctionne correctement. Utilisez une fenêtre de navigation privée, un compte de test propre et une séquence qui vérifie l'assertion, la décision réseau et l'expérience finale de l'utilisateur.

Commencez par la validation des métadonnées. Utilisez un traceur SAML ou un débogueur OIDC pour inspecter la réponse et confirmer le format NameID attendu, l'URI d'audience, l'émetteur, la signature et les revendications de groupe (group claims). Pour un flux basé sur RADIUS, confirmez que le courtier reçoit l'identité et renvoie une décision d'acceptation ou de rejet avec les attributs requis pour la cartographie des politiques.

Un graphique représentant une liste de contrôle pour tester et vérifier le flux d'authentification par authentification unique du personnel.

Tester par appareil et contexte réseau

Exécutez le flux sur différents types de terminaux plutôt que de supposer qu'un seul test de navigateur réussi couvre l'ensemble du parc :

  • Ordinateur portable géré : Utilisez un appareil joint au domaine sur le VLAN d'entreprise et confirmez que la politique du personnel attendue s'applique.
  • Téléphone BYOD : Connectez-vous depuis le SSID invité et vérifiez que les identifiants du personnel n'accordent pas accidentellement un accès réseau plus large.
  • Borne partagée : Testez le Captive Portal avec une session de navigation propre, puis déconnectez-vous et répétez l'opération avec un autre compte personnel.
  • Chemin de révocation : Modifiez ou désactivez le compte de test et confirmez qu'une nouvelle tentative d'authentification échoue et que les sessions existantes suivent la durée de vie configurée.

Vérifiez la durée de la session et la réauthentification forcée après un changement de mot de passe ou d'état du compte. Pour le 802.1X, inspectez les paquets de comptabilité RADIUS et confirmez que le point d'accès enregistre les événements de début, d'arrêt et d'identité attendus.

Mettre en corrélation les deux côtés de la transaction

Examinez conjointement les journaux du fournisseur d'identité et le flux d'événements de Purple. Les journaux de connexion Entra, le System Log d'Okta et les données d'audit de la console d'administration Google doivent indiquer la demande d'authentification, le résultat de la politique et l'identité de l'utilisateur. Purple doit afficher la demande correspondante et le résultat réseau.

Enregistrez l'ID de corrélation des deux systèmes dès que possible. Une simple horodate est souvent trop vague pendant une période d'activité intense, tandis qu'un identifiant partagé vous permet de distinguer une revendication de groupe rejetée d'un problème d'association sans fil. Capturez une trace réussie avant de modifier la configuration, afin que le centre d'assistance dispose d'un exemple de référence valide pour comparaison.

Plans de retour arrière et dépannage des pannes courantes

Un mardi à 9 h 00, un hôtel de 220 chambres active le SSO pour un groupe pilote. Le premier administrateur se connecte avec succès. Dix minutes plus tard, les premiers tickets arrivent au centre d'assistance en provenance du service d'étage, de la réception et de la restauration. Certains utilisateurs font face à une redirection infinie, d'autres atteignent l'IdP mais se retrouvent avec la mauvaise politique pour le personnel, et un ordinateur portable plus ancien refuse catégoriquement la connexion.

La réaction ne doit pas consister à désactiver tous les contrôles à la fois. Gardez le domaine RADIUS local activé comme solution de secours, rétablissez le profil du Captive Portal sur l'authentification par mot de passe en deux clics, et désactivez seulement ensuite la connexion SAML si le groupe pilote ne parvient toujours pas à s'authentifier. Cet ordre permet au personnel de continuer à travailler pendant que la fédération est isolée.

Modes de défaillance SSO courants et correctifs

Symptôme Cause probable Résolution
Assertion rejetée immédiatement Désalignement de l'horloge entre les systèmes Vérifiez la synchronisation de l'heure sur l'IdP, le service RADIUS, le contrôleur et le point d'accès. Utilisez la tolérance Purple documentée plutôt que de l'élargir inutilement.
La connexion boucle vers le portail Le cookie du Captive Portal entre en conflit avec la session de l'IdP Effacez la session du portail, testez dans une fenêtre de navigation privée et examinez le comportement des redirections et des cookies sur le profil du Captive Portal.
L'utilisateur s'authentifie mais n'obtient pas d'accès personnel Revendication de groupe manquante ou mal nommée Comparez l'assertion avec le mappage de groupe Purple, puis corrigez la revendication de l'IdP et testez à nouveau avec le compte pilote.
La connexion SAML échoue après un changement de certificat Certificat de signature expiré, non approuvé ou incorrectement importé Exportez les métadonnées IdP actuelles, validez le certificat de signature et importez les métadonnées actualisées dans l'enregistrement du fournisseur d'identité Purple.
La signature de l'assertion est rejetée Algorithme de signature non pris en charge ou incompatible Alignez l'algorithme de signature de l'IdP avec les exigences d'intégration et réimportez les métadonnées vérifiées.
Seuls certains utilisateurs échouent Attribution d'application ou appartenance à un groupe incorrecte Vérifiez l'attribution de l'application IdP de l'utilisateur, son appartenance au groupe et le mappage des politiques avant de modifier le réseau.

Ne supprimez pas l'ancien domaine tant que le nouveau parcours n'a pas passé les vérifications des appareils et que l'équipe d'assistance ne sait pas comment identifier une défaillance. Un retour en arrière n'est pas un échec de projet. C'est un contrôle normal qui évite qu'une opération d'authentification ne se transforme en panne de site.

L'expiration des certificats mérite une attention particulière car elle peut survenir sans aucune modification du parc sans fil. Enregistrez le propriétaire du certificat, le processus de renouvellement et l'emplacement d'importation. Pour les actualisations de métadonnées, validez le fichier et sa signature avant de remplacer la connexion active, puis testez le flux initié par le fournisseur de services (SP-initiated) depuis une session propre.

Meilleures pratiques de sécurité après le déploiement

Le SSO n'est fort que dans la mesure où le cycle de vie des identités qui le sous-tend l'est également. Une connexion centralisée peut améliorer le contrôle, mais elle peut aussi concentrer les risques si les administrateurs laissent des comptes inactifs, partagent trop d'attributs d'annuaire ou permettent à une identité de service partagée de contourner la politique normale.

Organisez une revue trimestrielle avec les équipes d'identité et de réseau. Confirmez que les nouveaux arrivants, les transferts et les départs apparaissent dans les bons groupes de personnel, que les comptes inactifs n'ont plus d'accès au réseau et que les modifications de groupe parviennent à la politique du personnel sans copie manuelle. Le guide du NCSC sur l'utilisation sécurisée de SaaS recommande une fédération d'identité complète dans les contextes cloud plutôt que la synchronisation des mots de passe dans le cloud, ce qui constitue un principe de conception utile pour les intégrations de réseau du personnel.

Contrôles à vérifier chaque trimestre

  • Utiliser une MFA résistante au phishing : Exigez des clés de sécurité FIDO2 ou des clés d'accès de plateforme pour les comptes d'IdP lorsque la plateforme et le parc d'appareils les prennent en charge. Traitez l'accès par SMS ou par mot de passe seul comme une exception de compatibilité, et non comme l'état cible.
  • Limiter la persistance des sessions : Définissez la durée de vie des sessions de l'IdP afin que la réauthentification Purple suive la politique de l'entreprise. Testez ce qui se passe après une déconnexion, la fermeture du navigateur, un changement de mot de passe et la désactivation du compte.
  • Vérifier l'accès juste-à-temps : Auditez les rôles du personnel temporaire et des invités pour identifier les attributions obsolètes. Supprimez l'accès dans le répertoire source plutôt que de vous fier à une liste manuelle dans la console réseau.
  • Surveiller le flux d'événements : Suivez les erreurs de fédération et les modèles de connexion inhabituels dans le tableau de bord Purple, puis corrélez-les avec les journaux de l'IdP.
  • Transmettre le minimum d'attributs : Envoyez uniquement les attributs requis par la politique du personnel, généralement l'adresse e-mail, le nom d'affichage et le groupe. Les données de répertoire inutiles n'ont pas leur place dans une assertion WiFi.
  • Renouveler les éléments de confiance : Renouvelez les certificats de signature et les secrets d'API avant leur expiration, testez le remplacement et ne gardez le certificat précédent disponible que pendant la fenêtre de transition approuvée.
  • Supprimer les identités partagées : Désactivez les comptes de service partagés partout où un appareil managé ou un utilisateur nommé peut effectuer la tâche. Si une exception subsiste, documentez son propriétaire et sa date de révision.

Les programmes d'identité au Royaume-Uni montrent pourquoi l'adoption et la réutilisation importent tout autant que l'authentification. L'analyse sectorielle 2026 de l'identité numérique de GOV.UK a rapporté que 77 % des personnes interrogées avaient réalisé au moins un cas d'usage d'identité numérique, tandis que 20 % des personnes ayant utilisé un service d'identité numérique ont déclaré avoir présenté une identité réutilisable. La leçon à retenir pour l'infrastructure informatique des sites est concrète : une connexion est utile, mais la régularité d'utilisation, l'assurance, l'accessibilité et le contrôle du cycle de vie déterminent si le SSO fonctionne sur l'ensemble des services réels.

Les directives de gestion des identités et des accès du NCSC soulignent également l'importance de désactiver les comptes et de propager cette décision aux services connectés. Maintenez cette propagation sous test. Le SSO n'est pas une configuration unique. Sa valeur apparaît lorsque les modifications de l'annuaire et les politiques réseau du personnel restent parfaitement synchronisées.

Une infographie présentant quatre bonnes pratiques de cybersécurité pour maintenir un accès réseau sécurisé après la mise en service.


Purple fournit une authentification WiFi pour le personnel qui connecte les fournisseurs d'identité tels que Microsoft Entra ID, Google Workspace, Okta et SAML 2.0 à un accès réseau géré, avec des politiques et des événements d'authentification gérés via sa plateforme. Visitez Purple pour évaluer un SSID destiné au personnel fédéré par l'identité pour vos hôtels, hôpitaux, points de vente ou autres sites, et planifier un projet pilote avec un plan de retour arrière testé.

Prêt à commencer ?

Réservez une démo avec l'un de nos experts pour voir comment Purple peut vous aider à atteindre vos objectifs commerciaux.

Parler à un expert