Aruba Central and Purple WiFi: Cloud-Managed Integration

Aruba Central et Purple WiFi : Intégration gérée dans le cloud. Un guide pour les responsables informatiques. Bienvenue. Si vous gérez le WiFi invité sur plusieurs sites et que vous utilisez Aruba Central, cet épisode vous concerne directement. Je vais vous expliquer exactement comment Purple s'intègre à Aruba Central — l'architecture, les étapes de configuration, les modèles de déploiement multi-sites et les pièges à éviter. Il s'agit d'un guide pratique, pas d'une présentation commerciale. Entrons dans le vif du sujet. Première partie : Contexte et importance. Aruba Central est la plateforme de gestion réseau dans le cloud de HPE. C'est le plan de contrôle de dizaines de milliers de bornes d'accès Aruba Instant déployées dans des hôtels, des chaînes de magasins, des stades, des centres de conférence et des bâtiments publics. Si vous êtes passé de contrôleurs Aruba sur site — les Mobility Controllers ou Mobility Conductors — à Central, vous avez déjà constaté la transition d'une configuration par site, très axée sur la CLI, vers une gestion des politiques basée sur des groupes et poussée depuis le cloud. Ce changement modifie fondamentalement la manière dont vous intégrez une plateforme de WiFi invité comme Purple. Sur un contrôleur Aruba traditionnel sur site, vous configureriez la redirection du Captive Portal et l'authentification RADIUS directement sur le contrôleur lui-même. Le contrôleur était le point d'application des politiques, situé dans votre centre de données ou votre salle informatique. Avec Aruba Central, l'application des politiques se fait toujours au niveau de la borne d'accès — mais la configuration est poussée depuis le cloud. Cela signifie que vos points de contact d'intégration sont différents. Vous travaillez avec des modèles de groupe, des profils SSID et des objets de profil de Captive Portal externe qui résident dans la hiérarchie de configuration d'Aruba Central, et non sur un équipement physique dans une baie. Purple se positionne au-dessus de tout cela en tant que plateforme intelligente de WiFi invité hébergée dans le cloud. Elle fournit le Captive Portal — la page d'accueil que les invités voient —, gère la logique d'authentification, capture les données de première partie avec consentement et transmet les analyses à vos équipes marketing et opérationnelles. La question est : comment connecter proprement ces deux plateformes cloud, à grande échelle, sur potentiellement des centaines de sites ? Deuxième partie : L'architecture technique. Laissez-moi vous décrire le flux de données lorsqu'un invité se connecte. L'appareil d'un invité s'associe à votre SSID invité — appelons-le Hotel-Guest — qui est diffusé par une borne d'accès Aruba Instant. La borne d'accès a été configurée, via Aruba Central, avec un profil de Captive Portal externe. Ce profil contient deux informations critiques : l'URL de redirection, qui pointe vers le serveur de Captive Portal de Purple, et les détails du serveur RADIUS, qui pointent vers le point de terminaison RADIUS-as-a-Service de Purple. Lorsque l'invité ouvre un navigateur, l'AP intercepte la requête HTTP et la redirige vers la splash page de Purple. L'invité s'authentifie — via un login social, un e-mail, un SMS ou un formulaire personnalisé, selon votre configuration Purple. Le backend de Purple renvoie ensuite un message RADIUS Access-Accept à l'AP, qui accorde à l'invité l'accès à Internet et le fait passer du rôle de pré-authentification au rôle d'invité authentifié. Les paquets de comptabilité RADIUS circulent tout au long de la session, offrant à Purple une visibilité sur la durée de la session et l'utilisation des données. La différence clé par rapport à Aruba sur site : dans Aruba Central, vous configurez le profil de Captive Portal externe une seule fois, au niveau du groupe, et il se propage à chaque AP de ce groupe. Vous ne touchez pas aux AP individuels. C'est extrêmement puissant pour les déploiements multi-sites, mais cela nécessite de définir correctement la structure du groupe avant de commencer. Aruba Central organise les appareils en Groupes, et au sein de ces groupes, vous pouvez avoir des Sites. Un Groupe est l'unité de configuration — les SSIDs, les profils radio et les politiques de sécurité résident tous au niveau du groupe. Les Sites sont l'unité de localisation et de surveillance. Pour une chaîne hôtelière, une structure logique consiste à créer un groupe par type de propriété — par exemple, Hôtels de luxe et Établissements économiques — chaque hôtel physique constituant un site distinct au sein du groupe approprié. La configuration de Purple s'associe ensuite aux groupes : un profil de Captive Portal externe par groupe, pointant vers le même endpoint RADIUS de Purple, mais potentiellement avec des thèmes de splash page différents par site grâce à la personnalisation au niveau du site de Purple. Le walled garden est un élément de configuration critique que les équipes configurent souvent de manière incorrecte. Avant qu'un invité ne s'authentifie, l'AP n'autorise que le trafic DNS et DHCP, ainsi que les domaines que vous ajoutez explicitement à la liste blanche. Pour que Purple fonctionne, vous devez inscrire sur liste blanche le domaine du Captive Portal de Purple, tous les domaines CDN utilisés par Purple pour les ressources, ainsi que les domaines des fournisseurs de login social si vous utilisez l'authentification sociale — Facebook, Google, Apple. Si vous oubliez un domaine, la splash page se chargera partiellement ou l'authentification échouera silencieusement. La documentation de support de Purple fournit la liste actuelle du walled garden, et il convient de traiter cette liste comme un document évolutif à réviser à chaque mise à jour de la plateforme par Purple. Section trois : l'API d'Aruba Central pour l'automatisation. Si vous déployez sur plus d'une vingtaine de sites, la configuration manuelle via l'interface utilisateur de Central devient un goulot d'étranglement. Aruba Central expose une API REST complète — l'API Central — qui vous permet d'automatiser la création de SSID, l'attribution de profils de Captive Portal et la configuration du walled garden. L'API est authentifiée via OAuth 2.0, et vous devrez générer des identifiants API depuis le portail Central. Les principaux points de terminaison API pour une intégration Purple sont : le point de terminaison de configuration WLAN, qui vous permet de créer et de mettre à jour les profils SSID ; le point de terminaison du profil de Captive Portal externe, où vous définissez l'URL de redirection Purple et les détails du serveur RADIUS ; et les points de terminaison de gestion des sites et des groupes, qui vous permettent d'attribuer des appareils à des sites et des groupes de manière programmatique. Si vous intégrez un nouveau site, vous pouvez écrire un script qui crée le site dans Central, attribue les points d'accès au site, applique le bon modèle de groupe et configure le profil de Captive Portal spécifique à Purple — le tout sans toucher à l'interface utilisateur. Purple expose également sa propre API, qui vous permet de créer des fiches d'établissement, de configurer des thèmes de portail de connexion et d'extraire des données analytiques. Une intégration mature utilisera les deux API ensemble : l'API de Central pour gérer la couche réseau, l'API de Purple pour gérer la couche d'expérience client. C'est le modèle que les grandes chaînes de vente au détail et les groupes hôteliers utilisent lorsqu'ils intègrent des dizaines de nouveaux sites par trimestre. Section quatre : Configuration étape par étape. Laissez-moi vous guider à travers la séquence de configuration pour un site unique, que vous automatiserez ensuite pour un déploiement à grande échelle. Tout d'abord, dans Aruba Central, accédez à votre groupe cible et ouvrez la configuration WLAN. Créez un nouveau SSID — par exemple, Venue-Guest — et définissez le niveau de sécurité sur Visiteurs. C'est la terminologie d'Aruba pour un réseau ouvert ou authentifié par Captive Portal. Deuxièmement, sous l'onglet Sécurité, définissez le type de portail de connexion sur Captive Portal externe. Créez un nouveau profil de Captive Portal externe. Donnez-lui un nom descriptif — Purple-Guest-Portal convient très bien. Définissez le type d'authentification sur Authentification RADIUS. Saisissez le nom d'hôte du serveur de Captive Portal de Purple dans le champ IP ou Nom d'hôte. Saisissez l'URL de redirection. Activez le protocole HTTPS. Définissez le comportement en cas d'échec du Captive Portal sur Refuser Internet, ce qui est l'option par défaut la plus sécurisée. Troisièmement, configurez le serveur RADIUS. Dans Central, accédez aux paramètres du serveur d'authentification et ajoutez le serveur RADIUS-as-a-Service de Purple. Vous aurez besoin de l'IP ou du nom d'hôte du serveur, du secret partagé — que vous générez dans la plateforme de Purple — et du port d'authentification, qui est le standard 1812, avec la comptabilisation (accounting) sur le 1813. Ajoutez ce serveur comme serveur principal pour votre SSID invité. Quatrièmement, configurez le walled garden (espace sécurisé). Dans les règles d'accès du SSID, ajoutez le domaine du Captive Portal de Purple et tous les domaines de connexion sociale à la liste d'autorisation. Testez cela attentivement — un domaine manquant est la cause la plus fréquente d'échec d'affichage du portail de connexion. Cinquièmement, enregistrez et déployez la configuration. Central déploiera la configuration sur tous les points d'accès du groupe. Vérifiez sur un appareil de test que la redirection se déclenche correctement et que l'authentification réussit. Section cinq : Modèles de déploiement multi-sites. Pour un déploiement sur cinquante sites ou plus, vous avez besoin d'une approche rigoureuse. Le modèle que je recommande est : pilote, modèle, automatisation, validation. Pilotez sur un seul site. Ajustez la configuration avec précision : walled garden complet, RADIUS opérationnel, page de connexion (splash page) se chargeant correctement, flux de comptabilisation actif. Documentez chaque valeur de paramètre. Ensuite, intégrez cette configuration dans un modèle de groupe Central. Ce modèle devient votre source unique de vérité. Pour le déploiement, utilisez l'API de Central pour pousser le modèle vers les nouveaux groupes à mesure que vous intégrez les sites. Si votre déploiement Purple utilise différents thèmes de splash page par marque ou par région, paramétrez le profil du Captive Portal — l'URL de redirection peut inclure des paramètres de requête que Purple utilise pour afficher le thème approprié. Cela signifie que vous pouvez avoir un seul point de terminaison RADIUS mais plusieurs expériences de splash page, le tout géré de manière centralisée. Validez chaque site après l'intégration. Un script de validation simple qui associe un appareil de test, vérifie la redirection, s'authentifie et valide l'accès à Internet permettra de détecter les dérives de configuration avant que les clients n'en fassent l'expérience. Le tableau de bord analytique de Purple vous indiquera également si les sessions sont enregistrées — si un site n'apparaît plus dans les rapports de Purple, c'est le signal que quelque chose est défaillant au niveau de la couche réseau. Section six : Pièges de mise en œuvre. Le walled garden est le premier point de défaillance. Testez avec un appareil qui n'a pas de cache DNS ni de sessions de portail enregistrées. Utilisez un profil de navigateur propre ou le mode de navigation privée. Le deuxième piège est une incompatibilité de la clé secrète partagée RADIUS. La clé secrète que vous configureg dans Central doit correspondre exactement à celle de la plateforme Purple. Une différence d'un seul caractère entraînera des échecs d'authentification silencieux — l'AP ne recevra aucune réponse du serveur RADIUS et refusera l'accès au client ou, si vous avez configuré le mode de défaillance du Captive Portal sur "Autoriser Internet", accordera l'accès sans authentification, ce qui représente un risque de conformité. Le troisième piège est une mauvaise configuration du VLAN. Le trafic invité doit se trouver sur un VLAN dédié, isolé de votre réseau d'entreprise. Dans Aruba Central, cela se configure dans les paramètres VLAN du profil SSID. Si votre VLAN invité n'est pas correctement trunké sur le port du commutateur de liaison montante, les AP s'activeront mais les invités n'obtiendront pas d'adresses DHCP. Le quatrième piège concerne la confiance du certificat lors de la redirection du Captive Portal. Les navigateurs et systèmes d'exploitation modernes sont de plus en plus stricts concernant l'application du protocole HTTPS. Le serveur de Captive Portal de Purple utilise un certificat TLS valide, mais si votre walled garden bloque les points de terminaison OCSP ou CRL que le client utilise pour valider le certificat, vous verrez des erreurs de certificat sur la splash page. Ajoutez ces points de terminaison à votre walled garden. Section sept : Questions rapides. Est-ce que Purple fonctionne avec l'architecture AOS-10 d'Aruba Central ainsi qu'avec AOS-8 ? Oui. Le mécanisme de Captive Portal externe est cohérent sur les deux flux de firmware. Le chemin dans l'interface utilisateur diffère légèrement, mais les objets de configuration sous-jacents sont les mêmes. Puis-je utiliser le RADIUS-as-a-Service de Purple sans gérer ma propre infrastructure RADIUS ? Oui, c'est tout l'intérêt. Le RADIUS-as-a-Service de Purple est un serveur RADIUS hébergé dans le cloud vers lequel vous pointez vos AP Aruba. Vous n'avez pas besoin de FreeRADIUS ou de Cisco ISE sur site. Cette intégration prend-elle en charge le WPA3 ? Aruba Central prend en charge le WPA3 sur les AP compatibles, et vous pouvez activer le mode de transition WPA3 sur votre SSID invité. Le mécanisme de Captive Portal de Purple est indépendant de la couche de chiffrement — il fonctionne au niveau de la redirection HTTP, et non au niveau de l'association 802.11. Les données collectées par Purple sont-elles conformes au GDPR ? Purple est conçu avec la conformité au GDPR comme exigence fondamentale. Le portail de connexion présente un mécanisme de consentement, et le traitement des données par Purple est régi par votre accord de traitement des données (DPA) avec eux. Pour les sites de l'UE, assurez-vous que votre configuration Purple inclut les mentions de consentement appropriées et que votre DPA est en place avant la mise en service. Section huit : Résumé et prochaines étapes. Pour résumer : Aruba Central et Purple s'intègrent via le mécanisme d'External Captive Portal, l'authentification RADIUS étant gérée par le service RADIUS cloud de Purple. La configuration réside au niveau du groupe dans Central et se propage à tous les AP du groupe — ce qui constitue la principale différence architecturale par rapport à Aruba sur site. Pour les déploiements multi-sites, utilisez l'API de Central pour automatiser le provisionnement et considérez la configuration de votre site pilote comme le modèle pour tout ce qui suit. Vos prochaines étapes immédiates : premièrement, confirmez que la structure de votre groupe Aruba Central correspond à la hiérarchie de vos sites Purple. Deuxièmement, obtenez la liste actuelle des domaines du walled garden de Purple et les détails des points de terminaison RADIUS auprès du portail d'assistance de Purple. Troisièmement, menez un projet pilote sur un seul site et validez l'ensemble du flux d'authentification avant de passer à l'échelle. Quatrièmement, créez vos scripts d'automatisation en utilisant l'API de Central et l'API de Purple en parallèle. Si vous évaluez Purple pour la première fois, les pages de la plateforme d'analyse et de WiFi invité sur purple.ai vous donneront une image claire de ce que vous obtenez au-delà du Captive Portal — la capture de données de première partie, l'automatisation du marketing, l'analyse de la fréquentation. C'est l'argument commercial qui permet de financer ce projet. Merci pour votre écoute. Si vous avez des questions sur cette intégration, l'équipe des solutions de Purple peut vous guider à travers une preuve de concept adaptée à votre environnement Aruba Central spécifique.