Passer au contenu principal

Authentification SAML pour le WiFi du personnel

Ce guide propose une analyse technique approfondie de l'utilisation de SAML 2.0 pour l'authentification WiFi du personnel de niveau entreprise, couvrant l'architecture du protocole, l'intégration du fournisseur d'identité et les meilleures pratiques de déploiement. Il fournit aux responsables informatiques et aux architectes réseau des conseils concrets pour connecter Azure AD ou Okta à la plateforme d'intelligence Purple WiFi afin de remplacer les clés pré-partagées non sécurisées par un contrôle d'accès robuste et basé sur l'identité. Le résultat est une amélioration mesurable de la posture de sécurité, de la conformité et de l'efficacité opérationnelle dans les hôtels, les chaînes de vente au détail, les stades et les espaces publics.

📖 7 min de lecture📝 1,588 mots🔧 2 exemples concrets3 questions d'entraînement📚 9 définitions clés

Écouter ce guide

Voir la transcription du podcast
Bienvenue dans ce point technique Purple. Aujourd'hui, nous vous proposons un guide de référence sur un sujet crucial pour tout exploitant de site de grande envergure : l'utilisation de l'authentification SAML pour le réseau WiFi de votre personnel. Si vous êtes responsable informatique, architecte réseau ou CTO, ce point vous apportera les informations concrètes dont vous avez besoin pour prendre une décision stratégique. Commençons par le contexte. Pendant des années, le WiFi du personnel dans les hôtels, les chaînes de magasins et les stades a été sécurisé par une simple clé pré-partagée. Un mot de passe écrit sur un tableau blanc dans la salle de pause. Nous savons tous que cela représente un risque de sécurité majeur et un casse-tête administratif. Cela n'offre aucune piste d'audit, et l'accès perdure bien après le départ d'un employé. La solution moderne consiste à traiter l'accès au réseau comme n'importe quelle autre application d'entreprise : en le liant à l'identité. C'est là qu'intervient SAML, le Security Assertion Markup Language. Passons maintenant à l'analyse technique. Comment cela fonctionne-t-il concrètement ? Imaginez l'annuaire de votre personnel — probablement Azure Active Directory ou Okta — comme votre bureau des passeports numériques. C'est votre fournisseur d'identité, ou IdP. La plateforme Purple, qui gère votre expérience WiFi, agit en tant que fournisseur de services, ou SP. Lorsqu'un membre du personnel se connecte au WiFi, un processus appelé flux initié par le SP commence. Son appareil est dirigé vers un Captive Portal, qui le redirige immédiatement vers votre page de connexion d'entreprise habituelle fournie par l'IdP. L'utilisateur saisit son adresse e-mail et son mot de passe professionnels habituels, et surtout, répond à toute invite d'authentification multifacteur. L'IdP, après avoir vérifié son identité, signe numériquement une assertion SAML — un document XML qui indique « Je valide cet utilisateur » — et la renvoie à la plateforme Purple. Purple valide cette assertion signée, confirme que l'utilisateur est autorisé et accorde à l'appareil l'accès au réseau. L'ensemble du processus est fluide, sécurisé et ne prend que quelques secondes. Vous avez remplacé un mot de passe partagé faible par une vérification d'identité robuste, signée par cryptographie et entièrement intégrée à votre pile de sécurité d'entreprise existante. Parlons de la mise en œuvre. Le cœur du déploiement consiste à établir une relation de confiance. Dans votre IdP, vous allez créer une nouvelle application d'entreprise pour Purple. Vous lui fournirez deux informations clés provenant de Purple : l'Entity ID et l'URL de l'Assertion Consumer Service. Considérez-les comme l'adresse postale pour les assertions SAML. En retour, votre IdP vous fournira ses propres métadonnées — son URL SSO, son Entity ID et, surtout, son certificat de signature public X.509. Vous configurez ces détails dans le portail Purple. La dernière étape, essentielle, consiste à configurer les revendications. Vous devez indiquer à l'IdP d'envoyer un identifiant d'utilisateur unique et permanent — et non une adresse e-mail — et, pour une efficacité maximale, d'envoyer les appartenances aux groupes de l'utilisateur. Cela vous permet de créer des règles d'accès puissantes basées sur les rôles directement dans Purple, sans avoir à gérer les autorisations individuelles des utilisateurs. Laissez-moi vous donner deux exemples concrets pour illustrer cela. Tout d'abord, prenons le cas d'une chaîne hôtelière mondiale comptant trois cents établissements. Elle utilise Microsoft 365 et Azure AD. Son équipe informatique crée une nouvelle application d'entreprise dans Azure AD pour Purple, configure les revendications pour envoyer l'appartenance au groupe et la lie à un SSID unique pour le personnel diffusé sur les trois cents établissements. Un nouveau membre du personnel, dans n'importe quel hôtel, se voit automatiquement accorder le bon niveau d'accès WiFi dès que son compte est ajouté au groupe concerné dans Azure AD. Pas de tickets. Pas de configuration manuelle. Pas d'attente. Deuxièmement, prenons l'exemple d'un grand centre de conférences qui accueille simultanément plusieurs événements tiers. Il doit fournir un accès WiFi sécurisé au personnel événementiel de différentes organisations, chacune ayant son propre système d'identité. Grâce à la capacité de Purple à prendre en charge plusieurs fournisseurs d'identité SAML, il configure une relation de confiance distincte pour chaque organisateur d'événement. L'organisateur A utilise Okta. L'organisateur B utilise Google Workspace. Le Captive Portal invite l'utilisateur à identifier son organisation, puis l'oriente vers le bon IdP. En utilisant les revendications de groupe, Purple associe les utilisateurs à des VLAN spécifiques à l'événement, garantissant une ségrégation complète du réseau. L'accès expire automatiquement à la fin de l'événement. C'est la gestion d'identité fédérée dans toute sa puissance. Quels sont maintenant les pièges courants et les recommandations ? La première cause d'échec est l'expiration du certificat. Ce certificat de signature X.509 a une durée de vie limitée. Vous devez mettre en place un processus pour le renouveler et le mettre à jour dans la plateforme Purple avant qu'il n'expire, sous peine de voir l'ensemble du WiFi de votre personnel cesser de fonctionner. Configurez plusieurs rappels à quatre-vingt-dix, soixante et trente jours avant l'échéance. Deuxièmement, imposez toujours l'authentification multifacteur. C'est votre outil le plus efficace contre le vol d'identifiants. Et troisièmement, utilisez les revendications de groupe pour affecter les utilisateurs à différents segments de réseau ou VLAN. C'est ainsi que vous garantissez qu'un terminal de point de vente ne peut accéder qu'au réseau de paiement, tandis que la tablette d'un responsable peut accéder aux ressources de l'entreprise. C'est de la segmentation réseau, pilotée par l'identité. Passons à une session rapide de questions-réponses. Trois questions courantes. Première question : Cela nécessite-t-il un logiciel spécial sur les appareils des utilisateurs ? Non. C'est toute la beauté de l'approche par Captive Portal. Elle utilise le navigateur web de l'appareil, de sorte qu'elle fonctionne sur pratiquement n'importe quel ordinateur portable, tablette ou smartphone sans configuration côté client. Deuxième question : Pouvons-nous utiliser cela pour le WiFi des invités ? C'est possible, mais ce n'est pas le cas d'usage principal. SAML est conçu pour les utilisateurs de confiance issus d'un annuaire connu. Pour l'accès public des invités, d'autres méthodes comme les connexions via les réseaux sociaux ou de simples codes d'accès sont généralement plus appropriées. Troisième question : Quel est le plus grand avantage ? L'automatisation. Lorsqu'un employé s'en va, vos équipes RH et informatiques disposent d'un processus pour désactiver son compte principal. En liant le WiFi à ce même compte, son accès au réseau est révoqué instantanément et automatiquement dans le cadre de ce flux de travail existant. Pas d'étapes supplémentaires. Pas de failles de sécurité. Pour résumer. La mise en œuvre de l'authentification SAML pour le WiFi du personnel fait passer la sécurité de votre réseau d'un modèle fragile basé sur des mots de passe à une architecture robuste basée sur l'identité. Elle renforce votre posture de sécurité, réduit considérablement les frais administratifs et offre une expérience fluide à votre personnel. Le retour sur investissement est clair et mesurable. Votre prochaine étape consiste à examiner votre infrastructure WiFi actuelle et votre fournisseur d'identité. Identifiez les principales parties prenantes et lancez la discussion sur la transition vers un cadre d'authentification moderne et sécurisé. Il ne s'agit pas seulement d'une mise à niveau technique, mais d'une amélioration fondamentale de vos opérations commerciales et de votre stratégie de gestion des risques. Merci d'avoir suivi ce point technique Purple. Pour obtenir des ressources plus approfondies et découvrir comment notre plateforme peut faciliter ce déploiement, visitez notre site à l'adresse purple dot ai. D'ici là, restez en sécurité.

header_image.png

Synthèse opérationnelle

Pour les exploitants de sites à grande échelle — chaînes hôtelières, empires du commerce de détail, grands espaces événementiels et infrastructures du secteur public — la sécurisation du réseau sans fil du personnel est un élément critique de la réduction des risques et de l'efficacité opérationnelle. Les réseaux traditionnels à clé pré-partagée (PSK) présentent d'importantes vulnérabilités de sécurité et une lourde charge administrative : un seul identifiant compromis expose l'ensemble du réseau, et la gestion des accès nécessite une intervention manuelle à chaque changement de personnel. Ce guide détaille une approche supérieure : la mise en œuvre d'une authentification basée sur Security Assertion Markup Language (SAML) 2.0 pour le WiFi du personnel. En intégrant votre fournisseur d'identité (IdP) existant — tel que Microsoft Azure Active Directory ou Okta — à la plateforme intelligente Purple, vous remplacez les mots de passe partagés non sécurisés par un contrôle d'accès robuste et basé sur l'identité. Ce modèle de déploiement élève votre niveau de sécurité conformément aux exigences PCI DSS et GDPR, et simplifie considérablement la gestion du cycle de vie des utilisateurs. Le personnel s'authentifie à l'aide de ses identifiants d'entreprise principaux, ce qui permet l'authentification unique (SSO) et garantit que les droits d'accès sont automatiquement révoqués en cas de départ. Pour le CTO, cela se traduit par une réduction mesurable des tickets de support informatique, une conformité renforcée et une architecture réseau plus solide et plus défendable.

Analyse technique approfondie

SAML est une norme ouverte pour l'échange de données d'authentification et d'autorisation entre les parties — spécifiquement entre un fournisseur d'identité (IdP) et un fournisseur de services (SP). Dans ce contexte, l'IdP est votre annuaire central d'utilisateurs (Azure AD, Okta, Ping Identity ou ADFS), et la plateforme Purple agit en tant que SP, gérant l'accès au réseau WiFi physique.

Le flux d'authentification SAML 2.0

Ce processus permet une authentification sécurisée via navigateur pour les utilisateurs du WiFi sans nécessiter l'installation de logiciel côté client. Lorsqu'un membre du personnel se connecte au SSID dédié au personnel, son appareil est redirigé vers un Captive Portal. Au lieu d'un simple champ de mot de passe, ce portail lance une liaison cryptographique en plusieurs étapes avec l'IdP pour vérifier l'identité de l'utilisateur.

saml_flow_diagram.png

Le flux se déroule en cinq étapes distinctes. Premièrement, l'utilisateur connecte son appareil — ordinateur portable, tablette ou téléphone mobile — au SSID WiFi du personnel, et la plateforme Purple présente un Captive Portal. Deuxièmement, Purple (agissant en tant que SP) génère une requête d'authentification SAML (AuthnRequest), un document XML contenant des informations sur le SP et les paramètres d'authentification souhaités. Le navigateur de l'utilisateur est redirigé vers l'URL SSO de l'IdP avec cette requête intégrée. Troisièmement, l'utilisateur arrive sur la page de connexion familière de l'IdP — son écran Microsoft 365 ou Okta — et saisit ses identifiants d'entreprise. L'IdP applique ici toute sa gamme de politiques de sécurité, y compris l'authentification multifacteur (MFA), les vérifications de confiance des appareils et les règles d'accès conditionnel. Quatrièmement, une fois l'authentification réussie, l'IdP génère une réponse SAML contenant une assertion signée numériquement. Cette assertion est signée avec la clé privée de l'IdP et contient des informations clés sur l'utilisateur authentifié, notamment son nom d'utilisateur, son adresse e-mail et ses appartenances à des groupes. Le navigateur de l'utilisateur est redirigé vers l'URL du service consommateur d'assertions (ACS) de Purple avec cette réponse signée. Cinquièmement, Purple reçoit la réponse SAML, vérifie la signature numérique à l'aide du certificat public préconfiguré de l'IdP, analyse l'assertion pour confirmer l'autorisation et demande au contrôleur réseau d'accorder à l'appareil un accès complet au réseau.

Normes et protocoles pertinents

SAML 2.0 est le protocole fondamental, définissant les messages basés sur XML pour les assertions, les protocoles, les liaisons et les profils. La norme IEEE 802.1X fournit un contrôle d'accès réseau basé sur les ports complémentaire ; cependant, l'approche SAML par Captive Portal offre une compatibilité universelle des appareils sans nécessiter de configuration complexe de demandeur sur chaque terminal, ce qui la rend idéale pour les environnements BYOD. Le WPA3-Enterprise, lorsqu'il est combiné avec SAML, offre une défense en profondeur : le WPA3 chiffre le trafic aérien tandis que SAML gère la vérification de l'identité au niveau de la couche applicative. L'exigence 8 de la norme PCI DSS impose l'identification et l'authentification des accès aux composants du système, une exigence directement traitée par cette architecture.

idp_comparison_infographic.png

Guide de mise en œuvre

Le déploiement de l'authentification SAML pour le WiFi de votre personnel implique l'établissement d'une relation de confiance cryptographique entre votre IdP et la plateforme Purple. Les étapes suivantes sont indépendantes des fournisseurs, bien que les éléments d'interface utilisateur spécifiques varient selon l'IdP.

Liste de contrôle avant déploiement

Avant de commencer la configuration, confirmez que vous disposez d'un IdP compatible SAML 2.0 (Azure AD, Okta, Ping Identity, ADFS). Assurez-vous de disposer de privilèges d'administrateur à la fois dans votre portail IdP et dans la plateforme Purple. Définissez vos groupes d'utilisateurs — par exemple, « Tout le personnel », « Administrateurs informatiques », « Directeurs de magasin » — car ce sont eux qui régissent les politiques d'accès basées sur les rôles. Vérifiez que votre matériel WiFi (points d'accès et contrôleurs) prend en charge la redirection vers le Captive Portal.

Étape 1 — Configurer l'application dans votre IdP

Dans votre IdP, créez une nouvelle application basée sur SAML pour Purple. Accédez à « Applications d'entreprise » dans Azure AD ou « Applications » dans Okta et sélectionnez une application SAML personnalisée. Vous devrez fournir à votre IdP deux valeurs provenant de Puplateforme Purple : l'URL de l'Assertion Consumer Service (ACS) et l'ID d'entité. Purple fournit ces informations dans sa section de configuration de l'authentification. En retour, votre IdP générera ses propres métadonnées — généralement un fichier XML ou une URL — contenant l'URL de SSO de l'IdP, l'ID d'entité et le certificat de signature X.509. Conservez ces éléments pour l'étape suivante.

Étape 2 — Configurer les revendications (Claims)

Il s'agit de l'étape de configuration la plus importante sur le plan opérationnel. Vous devez configurer l'IdP pour qu'il envoie des attributs utilisateur spécifiques dans l'assertion SAML. Purple requiert un identifiant unique et persistant pour chaque utilisateur en tant que revendication NameID. La bonne pratique consiste à utiliser un attribut immuable tel que user.objectid dans Azure AD ou user.id dans Okta, plutôt qu'une adresse e-mail modifiable. De plus, configurez les revendications de groupe pour transmettre les appartenances aux groupes de l'utilisateur. Cela permet d'activer des politiques d'accès dynamiques basées sur les rôles au sein de Purple sans configuration par utilisateur.

Étape 3 — Configurer la méthode d'authentification dans Purple

Dans le portail Purple, accédez à la section de gestion de l'authentification et sélectionnez SAML 2.0 comme type de méthode. Saisissez l'URL de SSO de l'IdP, l'ID d'entité et le certificat X.509 obtenus à l'étape 1. Associez les noms d'attributs de la configuration des revendications de votre IdP aux champs correspondants dans Purple. Enfin, attribuez cette méthode d'authentification au parcours de votre Captive Portal pour le personnel afin d'activer le flux pour les utilisateurs se connectant au SSID du personnel.

Étape 4 — Tests et déploiement progressif

Attribuez la nouvelle application SAML à un petit groupe pilote — idéalement l'équipe informatique — et validez le flux de bout en bout sur plusieurs types d'appareils (Windows, macOS, iOS, Android). Surveillez les journaux de connexion SAML dans votre IdP et les journaux d'authentification dans Purple pour diagnostiquer les éventuels échecs. Une fois validé, élargissez progressivement l'attribution des utilisateurs dans votre IdP pour couvrir tous les groupes de personnel concernés. Communiquez clairement le changement au personnel, en soulignant qu'ils utiliseront désormais leurs identifiants de connexion d'entreprise habituels.

Bonnes pratiques

Imponez la MFA pour toutes les authentifications WiFi. C'est le contrôle le plus efficace contre le vol d'identifiants et doit être considéré comme non négociable pour tout déploiement en entreprise. Tirez parti des capacités d'accès conditionnel de votre IdP pour restreindre l'accès au réseau en fonction de l'état de conformité de l'appareil, de la situation géographique ou du score de risque. Configurez des délais d'expiration de session courts dans Purple pour forcer une réauthentification périodique, garantissant ainsi que les droits d'accès sont régulièrement revalidés auprès de l'IdP et limitant les risques liés aux appareils perdus ou volés. Respectez le principe de minimisation des attributs : n'incluez dans l'assertion SAML que les attributs nécessaires aux décisions d'accès, conformément au principe de minimisation des données de l'article 5 du GDPR. Pour les appareils gérés par l'entreprise, envisagez de combiner le Captive Portal SAML avec WPA3-Enterprise et 802.1X pour une défense en profondeur ; l'approche SAML est la plus adaptée au BYOD ou aux terminaux non gérés.

venue_staff_wifi.png

Dépannage et atténuation des risques

Le mode de défaillance le plus courant et le plus impactant est l'expiration du certificat. Le certificat de signature X.509 de l'IdP a une période de validité fixe, généralement de un à trois ans. Lorsqu'il expire, Purple ne peut plus valider les assertions SAML, ce qui entraîne une interruption complète de l'authentification. Atténuation : configurez des rappels de calendrier redondants à 90, 60 et 30 jours avant l'expiration et documentez explicitement la procédure de renouvellement.

Le désalignement temporel (clock skew) est la deuxième cause la plus fréquente d'échecs d'authentification. Les assertions SAML contiennent une fenêtre de validité, et si les horloges de l'IdP et de la plateforme Purple divergent de plus de quelques minutes, les assertions seront rejetées comme expirées ou non encore valides. Assurez-vous que les deux systèmes se synchronisent sur une source NTP fiable.

Une URL ACS incorrecte lors de la configuration initiale est une erreur de configuration courante. Une simple faute de frappe signifie que l'IdP envoie l'assertion signée vers un point de terminaison inexistant. Copiez-collez toujours l'URL ACS directement depuis la plateforme Purple plutôt que de la saisir manuellement.

Enfin, désactivez la connexion initiée par l'IdP pour cette application. L'accès au réseau ne doit jamais être initié que depuis le SP (l'événement de connexion WiFi). Autoriser les flux initiés par l'IdP ouvre la porte à certaines attaques par injection basées sur SAML et constitue un risque de sécurité inutile dans ce modèle de déploiement.

ROI et impact commercial

L'analyse de rentabilisation de l'authentification WiFi du personnel basée sur SAML est convaincante pour tous les types d'établissements. L'élimination des mots de passe partagés supprime le besoin de rotations périodiques et perturbatrices des mots de passe ainsi que les tickets d'assistance associés. Les organisations signalent généralement une réduction de plus de 50 % des demandes de support informatique liées au WiFi après le déploiement. L'automatisation du cycle de vie des utilisateurs est le gain opérationnel le plus important : lorsqu'un membre du personnel quitte l'entreprise et que son compte IdP est désactivé, son accès WiFi est révoqué instantanément et automatiquement, comblant ainsi une faille de sécurité que les réseaux basés sur PSK laissent ouverte indéfiniment. Du point de vue de la conformité, SAML fournit un journal d'accès auditable au niveau individuel, répondant directement à l'exigence 8 de PCI DSS et aux obligations de responsabilité du GDPR. L'expérience SSO fluide — un seul ensemble d'identifiants pour la messagerie, les applications et le WiFi — réduit les frictions pour le personnel et augmente la productivité, en particulier pour les équipes opérationnelles qui se déplacent entre les différentes zones d'un site tout au long de la journée.


Références

[1] OASIS Security Services (SAML) TC. "SAML V2.0 Executive Overview." Avril 2008. https://www.oasis-open.org/committees/download.php/27819/sstc-saml-exec-overview-2.0-cd-01.pdf

[2] Règlement général sur la protection des données (GDPR). Article 5, Principes relatifs au traitement des données à caractère personnel. https://gdpr-info.eu/art-5-gdpr/

[3] PCI Security Standards Council. "PCI DSS v4.0 Requirement 8: Identify Users and Authenticate Access to System Components." 2022. https://www.pcisecuritystandards.org/

Définitions clés

Assertion SAML

Un document XML, signé numériquement par le fournisseur d'identité, qui déclare l'identité d'un utilisateur et fournit des attributs supplémentaires à son sujet. C'est le « passeport numérique » cryptographique auquel le fournisseur de services fait confiance pour prendre une décision d'accès.

Lors du dépannage des échecs d'authentification, les équipes informatiques inspectent l'assertion SAML pour vérifier que l'IdP envoie les attributs utilisateur corrects et que la signature numérique est valide. C'est la preuve centrale de chaque transaction d'authentification.

Fournisseur d'identité (IdP)

Le système qui gère les identités des utilisateurs et les authentifie. Il s'agit de la source unique de vérité pour l'identité des utilisateurs au sein d'une organisation.

Dans un environnement d'entreprise, il s'agit de l'annuaire central des utilisateurs — Azure AD, Okta, Ping Identity ou ADFS. C'est là que les équipes informatiques ajoutent, suppriment et gèrent tous les comptes du personnel et appliquent les politiques de sécurité comme le MFA.

Fournisseur de services (SP)

L'application ou le service qui nécessite une authentification avant d'accorder l'accès. Il fait confiance au fournisseur d'identité pour effectuer l'authentification et s'appuie sur l'assertion SAML comme preuve.

Pour l'authentification WiFi SAML, la plateforme Purple est le fournisseur de services. Elle consomme l'assertion SAML de l'IdP pour prendre une décision de contrôle d'accès réseau pour l'appareil qui se connecte.

URL de l'Assertion Consumer Service (ACS)

Un point de terminaison spécifique sur le fournisseur de services conçu pour recevoir et traiter les assertions SAML du fournisseur d'identité après un événement d'authentification réussi.

Il s'agit de l'un des paramètres de configuration les plus critiques. Si l'URL ACS est mal saisie dans les paramètres de l'IdP, ce dernier ne saura pas où rediriger l'utilisateur après sa connexion, et l'authentification échouera avec une erreur de redirection.

Entity ID

Un identifiant unique au monde pour un fournisseur d'identité ou un fournisseur de services au sein du protocole SAML. Il agit comme un nom unique pour s'assurer que chaque partie communique avec le bon interlocuteur.

Généralement formaté sous forme d'URL, l'Entity ID n'a pas besoin de correspondre à une page web réelle. Il fonctionne comme un identifiant unique dans un annuaire, empêchant un SP de consommer accidentellement des assertions destinées à un autre.

Métadonnées SAML

Un document XML contenant toutes les informations de configuration nécessaires sur une partie SAML — y compris son Entity ID, les URL des points de terminaison (tels que l'URL ACS) et le certificat de signature public X.509.

L'échange de fichiers de métadonnées est la méthode la plus fiable pour configurer une relation de confiance SAML. Plutôt que de copier manuellement des valeurs individuelles, les administrateurs peuvent télécharger le XML de métadonnées de l'autre partie pour pré-remplir la configuration, réduisant ainsi le risque d'erreurs de saisie.

Revendication (Claim)

Une information sur un utilisateur — un attribut — qui est incluse dans l'assertion SAML par le fournisseur d'identité. Les revendications courantes incluent le nom d'utilisateur, l'adresse e-mail, le service et les appartenances aux groupes.

Les équipes informatiques configurent les revendications dans l'IdP pour contrôler les informations que le SP reçoit. L'envoi de revendications d'appartenance à un groupe à Purple permet d'appliquer des politiques d'accès basées sur les rôles et une attribution dynamique de VLAN en fonction de la fonction de l'utilisateur.

Single Sign-On (SSO)

Un schéma d'authentification qui permet à un utilisateur de s'authentifier une seule fois avec un ensemble unique d'identifiants et d'accéder à plusieurs systèmes et applications indépendants sans avoir à ressaisir ses identifiants pour chacun d'eux.

SAML est l'un des principaux facilitateurs techniques du SSO. En utilisant SAML pour l'authentification WiFi, le personnel utilise la même connexion d'entreprise que pour la messagerie, les systèmes RH et d'autres applications pour se connecter — une expérience fluide qui réduit les frictions et élimine le besoin de mots de passe WiFi distincts.

Certificat X.509

Une norme de certificat numérique utilisée pour vérifier l'identité d'une partie et pour signer ou chiffrer des données. Dans SAML, l'IdP utilise sa clé privée pour signer les assertions, et le SP utilise le certificat public X.509 de l'IdP pour vérifier ces signatures.

Ce certificat est le fondement de la confiance dans un déploiement SAML. Son expiration est la cause la plus fréquente d'interruption complète de l'authentification et doit être gérée de manière proactive.

Exemples concrets

Une chaîne hôtelière mondiale comptant 300 établissements doit remplacer sa clé PSK unique et non sécurisée pour le WiFi du personnel. La chaîne utilise Microsoft 365 et Azure AD comme plateforme d'identité d'entreprise. Elle a besoin d'une solution gérée de manière centralisée, offrant une expérience fluide au personnel et révoquant immédiatement l'accès lorsqu'un employé quitte l'organisation.

L'équipe informatique crée une nouvelle application d'entreprise dans Azure AD pour la plateforme Purple. Elle configure l'application avec l'Entity ID et l'URL ACS de son instance Purple. De manière cruciale, elle configure les revendications (claims) pour envoyer l'appartenance au groupe de l'utilisateur — par exemple, 'Hotel-Staff' et 'IT-Admin' — et utilise user.objectid comme NameID unique pour garantir un identifiant stable et immuable. Dans Purple, elle crée une nouvelle méthode d'authentification SAML, en téléchargeant le XML de métadonnées Azure AD pour établir la relation de confiance. Elle crée ensuite deux politiques d'accès : une pour 'Hotel-Staff' qui accorde l'accès au VLAN du réseau général du personnel, et une seconde pour 'IT-Admin' qui accorde un accès privilégié au VLAN de gestion. Cette configuration est liée à un unique SSID 'Staff' diffusé sur les 300 établissements via la plateforme de gestion de réseau centralisée de la chaîne. Un nouveau membre du personnel dans n'importe quel hôtel se voit automatiquement attribuer le bon niveau d'accès WiFi dès que son compte utilisateur est ajouté au groupe concerné dans Azure AD — aucune intervention informatique locale n'est requise. Lorsqu'un employé s'en va, la désactivation de son compte Azure AD révoque immédiatement son accès WiFi sur les 300 établissements simultanément.

Commentaire de l'examinateur : Il s'agit d'un exemple parfait de gestion des accès réseau évolutive et basée sur l'identité. En s'appuyant sur les revendications de groupe Azure AD, la chaîne hôtelière évite de gérer des politiques d'accès par utilisateur ou par établissement, ce qui serait impossible à gérer sur le plan opérationnel pour 300 sites. L'utilisation de `user.objectid` garantit un identifiant stable même si le nom ou l'adresse e-mail de l'utilisateur change — un cas fréquent dans les grandes organisations du secteur de l'hôtellerie. Cette architecture offre un excellent ROI en centralisant le contrôle et en automatisant le cycle de vie des utilisateurs, réduisant considérablement la charge administrative de l'équipe informatique centrale et éliminant la faille de sécurité inhérente aux mots de passe partagés.

Un grand centre de conférences accueille simultanément plusieurs événements tiers. Il doit fournir un accès WiFi sécurisé au personnel événementiel de différentes organisations, chacune ayant son propre système d'identité. Il ne peut pas délivrer d'identifiants au personnel externe et doit s'assurer que le personnel d'un événement ne peut pas accéder aux ressources réseau d'un autre.

L'équipe informatique du centre de conférences utilise la prise en charge par Purple de multiples fournisseurs d'identité SAML. Pour chaque organisateur d'événement majeur, elle configure une relation de confiance SAML distincte au sein de la plateforme Purple. L'organisateur A (utilisant Okta) et l'organisateur B (utilisant Google Workspace) sont configurés comme des IdP distincts. Le Captive Portal est configuré pour présenter une étape de sélection de l'organisation, orientant les utilisateurs vers leur IdP respectif pour l'authentification. En utilisant les revendications de groupe transmises par chaque IdP, Purple associe les utilisateurs à des VLAN spécifiques à l'événement, garantissant une ségrégation complète du trafic réseau entre les événements. L'accès pour le personnel de chaque organisateur expire automatiquement à la fin de l'événement en fonction des règles de parcours prédéfinies configurées dans Purple, ne nécessitant aucun déprovisionnement manuel.

Commentaire de l'examinateur : Cela démontre un cas d'usage multi-locataire sophistiqué qui illustre la véritable puissance de la gestion d'identité fédérée. Au lieu de traiter SAML comme une connexion unique et monolithique, l'exploitant du site l'utilise comme un cadre flexible pour intégrer et séparer en toute sécurité les utilisateurs temporaires de plusieurs organisations de confiance simultanément. Ce modèle est hautement sécurisé car il confie la responsabilité de la vérification de l'identité aux organisateurs d'événements eux-mêmes — la source faisant autorité pour leurs propres listes de personnel — plutôt que d'obliger le site à gérer des identifiants externes. Il est également efficace sur le plan opérationnel, car l'expiration automatique des accès supprime le besoin de déprovisionnement manuel après chaque événement.

Questions d'entraînement

Q1. Votre directeur financier a signalé que l'appareil personnel d'un ancien employé était toujours connecté au réseau WiFi du personnel deux semaines après son départ. Votre système actuel utilise une clé WPA2-PSK unique qui est renouvelée chaque trimestre. Comment une approche basée sur SAML atténuerait-elle ce risque spécifique, et quelles commandes supplémentaires recommanderiez-vous ?

Conseil : Prenez en compte le cycle de vie de l'utilisateur, la source de l'autorité d'authentification et le rôle des expirations de session.

Voir la réponse type

Une approche basée sur SAML lie directement l'accès WiFi au statut actif de l'employé dans le fournisseur d'identité central. Dès que le compte de l'employé est désactivé ou supprimé dans le cadre du processus standard de départ, sa capacité à s'authentifier auprès de tout service intégré à SAML — y compris le WiFi — est instantanément et automatiquement révoquée. L'IdP ne délivrera plus d'assertion SAML valide pour cet utilisateur, ce qui signifie qu'il ne pourra pas se réauthentifier. Pour gérer le cas spécifique d'un appareil déjà connecté, configurez des durées de session courtes dans Purple (par exemple, des sessions de 8 heures alignées sur une journée de travail). À l'expiration de la session, l'appareil doit se réauthentifier ; le compte IdP désactivé empêchera cette action. Cela élimine la faille de sécurité inhérente aux secrets partagés à longue durée de vie comme une clé PSK, où un appareil déjà connecté reste en ligne indéfiniment.

Q2. Un stade met en œuvre l'authentification SAML pour ses 500 collaborateurs les jours d'événement. Il souhaite s'assurer que les caissiers utilisant des terminaux de point de vente ne puissent accéder qu'au segment de réseau conforme à la norme PCI, tandis que le personnel opérationnel peut accéder au réseau d'entreprise général. Comment concevriez-vous la configuration des revendications SAML et la politique réseau pour parvenir à cette segmentation ?

Conseil : Réfléchissez à la manière de transmettre les informations de rôle de l'IdP à l'infrastructure réseau via l'assertion SAML, et à la manière dont Purple peut exploiter ces informations.

Voir la réponse type

La solution consiste à utiliser des revendications de groupe et une attribution dynamique de VLAN. Dans l'IdP (Azure AD ou Okta), créez deux groupes de sécurité : 'POS-Staff' et 'Ops-Staff'. Configurez l'application SAML pour inclure l'appartenance au groupe de l'utilisateur en tant que revendication dans l'assertion. Dans la plateforme Purple, créez deux profils d'accès utilisateur qui correspondent à ces noms de groupes. Configurez le profil 'POS-Staff' pour affecter les utilisateurs au VLAN conforme PCI (par exemple, VLAN 10) et le profil 'Ops-Staff' pour affecter les utilisateurs au VLAN d'entreprise (par exemple, VLAN 20). Lorsqu'un utilisateur s'authentifie, Purple lit la revendication de groupe dans l'assertion SAML et demande au contrôleur réseau — via des attributs RADIUS ou une API — de placer l'appareil de l'utilisateur dans le VLAN approprié. Le trafic réseau est alors segmenté au niveau de l'infrastructure, garantissant que les terminaux de point de vente ne peuvent atteindre que le réseau de traitement des paiements, quel que soit l'endroit où ils se connectent dans le stade.

Q3. Vous planifiez le déploiement de l'authentification WiFi SAML pour une chaîne de vente au détail de 1 000 magasins. Les directeurs de magasin n'ont pas de compétences techniques particulières. Quel est le risque opérationnel le plus important à gérer de manière proactive, et quels sont vos plans de communication et d'urgence ?

Conseil : Quel est le seul composant de la relation de confiance SAML qui a une date d'expiration fixe et dont la défaillance provoquerait une panne simultanée dans les 1 000 magasins ?

Voir la réponse type

Le risque opérationnel le plus critique est l'expiration du certificat de signature SAML de l'IdP. S'il expire, les 1 000 magasins perdront simultanément l'accès WiFi du personnel, car Purple sera incapable de valider les assertions SAML. Le plan d'atténuation comporte deux volets. Sur le plan technique : configurez plusieurs rappels de calendrier redondants pour la date d'expiration du certificat pour toute l'équipe informatique, à partir de 90 jours avant l'échéance. Documentez la procédure étape par étape pour générer un nouveau certificat dans l'IdP et le mettre à jour dans la plateforme Purple. Assurez-vous qu'au moins deux membres de l'équipe sont formés à cette procédure. Visez à finaliser le renouvellement au moins 30 jours avant l'expiration pour permettre des phases de test. Pour la communication : informez proactivement le directeur des opérations du réseau de vente de la fenêtre de maintenance prévue pour le renouvellement du certificat. Il n'est pas nécessaire d'informer les directeurs de magasin individuels pour un renouvellement planifié, car l'objectif est une transition sans interruption de service. En cas de panne imprévue, le plan de communication doit consister à informer immédiatement le directeur des opérations du problème et à lui fournir un délai de résolution réaliste. Une solution de secours temporaire — telle qu'une clé PSK à durée limitée pour les opérations critiques — doit être documentée dans le plan de continuité d'activité.

Continuer la lecture de cette série

Per-Device PSK par constructeur : iPSK, DPSK, MPSK et PPSK comparés (et support de WPA3)

Une comparaison complète des implémentations de per-device PSK chez Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Extreme, Fortinet et Ubiquiti UniFi. Découvrez comment le WPA3-SAE impacte les stratégies de clés par appareil et quand déployer des modes de transition par rapport à une migration vers le 802.1X.

Lire le guide →

Comparatif des méthodes d'authentification par Captive Portal

Ce guide de référence technique et d'autorité évalue les compromis architecturaux, opérationnels et de conformité des cinq principales méthodes d'authentification par captive portal. Il fournit aux architectes réseau, directeurs informatiques et responsables marketing les données quantitatives et les cadres de décision nécessaires pour équilibrer la friction d'intégration des invités avec les exigences de collecte de données au sein des sites d'entreprise.

Lire le guide →

Qu'est-ce que l'authentification par adresse MAC ? Quand l'utiliser et quand l'éviter

Ce guide de référence technique faisant autorité couvre l'authentification par adresse MAC dans les environnements WiFi d'entreprise — comment fonctionne l'authentification MAC basée sur RADIUS au niveau de la couche 2, ses vulnérabilités de sécurité inhérentes (y compris le spoofing MAC et l'impact de la randomisation MAC au niveau du système d'exploitation), et les contextes opérationnels précis où elle reste un outil valable pour gérer l'IoT et les appareils sans écran (headless). Il fournit des conseils de déploiement exploitables pour les responsables informatiques et les architectes réseau dans les secteurs de l'hôtellerie, du commerce de détail, de la santé et des espaces publics, avec des exemples concrets, des cadres de décision et le contexte d'intégration pour le WiFi invité et la plateforme d'analyse de Purple.

Lire le guide →