Aruba Central et Purple WiFi : Intégration gérée dans le Cloud

Aruba Central et Purple WiFi : Intégration gérée dans le cloud. Un briefing pour les leaders 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 qui piègent les équipes. Il s'agit d'un briefing pratique, pas d'un argumentaire produit. Entrons dans le vif du sujet. Première section : Contexte et importance. Aruba Central est la plateforme de mise en réseau gérée dans le cloud de HPE. C'est le plan de contrôle pour des dizaines de milliers d'Aruba Instant Access Points déployés dans des hôtels, des chaînes de magasins, des stades, des centres de conférence et des bâtiments du secteur public. Si vous êtes passé de contrôleurs Aruba sur site - les Mobility Controllers ou Mobility Conductors - à Central, vous avez déjà fait l'expérience de la transition d'une configuration lourde en CLI et spécifique au site vers une gestion des politiques basée sur des groupes et poussée par le cloud. Ce changement modifie fondamentalement la façon dont vous intégrez une plateforme de WiFi invité comme Purple. Sur un contrôleur Aruba sur site traditionnel, vous deviez configurer 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 de la politique, et il se trouvait dans votre centre de données ou votre salle de communication. Avec Aruba Central, l'application de la politique se fait toujours au niveau de l'Access Point - 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 de Central, et non sur un boîtier dans un rack. Purple se positionne au-dessus de tout cela en tant que plateforme d'intelligence de WiFi invité hébergée dans le cloud. Elle fournit le Captive Portal - la page de redirection que les invités voient - elle gère la logique d'authentification, elle capture les données de première partie avec consentement, et elle alimente vos équipes marketing et opérationnelles en analyses. La question est : comment connecter proprement ces deux plateformes cloud, à grande échelle, sur potentiellement des centaines de sites ? Section deux : L'architecture technique. Laissez-moi vous décrire le flux de données lorsqu'un invité se connecte. Un appareil invité s'associe à votre SSID invité - appelons-le Hotel-Guest - qui est diffusé par un Aruba Instant AP. L'AP a été configuré, 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 une connexion sociale, 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 transitent tout au long de la session, offrant à Purple une visibilité sur la durée de la session et l'utilisation des données. À présent, la différence clé par rapport à Aruba sur site : dans Aruba Central, vous configurez le profil d'External Captive Portal 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 vous oblige à structurer correctement vos groupes 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 SSID, les profils radio, 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 est de configurer un groupe par type de propriété - par exemple, Hôtels à Service Complet et Propriétés Budget - chaque hôtel physique constituant un site distinct au sein du groupe approprié. La configuration de Purple s'associe ensuite aux groupes : un profil d'External Captive Portal par groupe, pointant vers le même point de terminaison RADIUS de Purple, mais potentiellement avec des thèmes de splash page différents par site grâce à la personnalisation au niveau des sites 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 autorise uniquement le trafic DNS et DHCP, ainsi que tous les domaines que vous mettez explicitement sur 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 d'authentification sociale 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 fois que Purple met à jour sa plateforme. Section trois : interface de l'API Aruba Central pour l'automatisation. Si vous effectuez un déploiement sur plus de vingt sites environ, 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 par OAuth 2.0, et vous devrez générer des identifiants API depuis le portail de 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 de 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'affecter 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 AP 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 seul site, 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 le paramètre par défaut le plus sécurisé. 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'adresse 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 port standard 1812, avec l'analyse de trafic (accounting) sur le 1813. Ajoutez ce serveur comme serveur principal pour votre SSID invité. Quatrièmement, configurez le jardin d'enfants (walled garden). 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 avec soin - 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 va déployer la configuration sur tous les AP 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 : piloter, modéliser, automatiser, valider. Pilotez sur un seul site. Ajustez la configuration avec précision - walled garden complet, RADIUS opérationnel, page de connexion se chargeant correctement, comptabilité fluide. 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 envoyer le modèle aux nouveaux groupes au fur et à mesure de l'intégration des sites. Si votre déploiement Purple utilise différents thèmes de page de connexion 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 bon thème. Cela signifie que vous pouvez avoir un point de terminaison RADIUS unique mais plusieurs expériences de page de connexion, le tout géré de manière centralisée. Validez chaque site après l'intégration. Un simple script de validation qui associe un appareil de test, vérifie la redirection, s'authentifie et vérifie l'accès internet détectera les dérives de configuration avant que les clients ne les subissent. Le tableau de bord analytique de Purple vous indiquera également si les sessions sont enregistrées - si un site devient inactif dans les rapports de Purple, c'est le signal que quelque chose ne va pas au niveau de la couche réseau. Section six : Pièges de mise en œuvre. Le walled garden est le point de défaillance numéro un. Testez avec un appareil qui n'a pas de cache DNS ni de sessions de portail actives. Utilisez un profil de navigateur vierge ou le mode navigation privée. Le deuxième piège est un écart de secret partagé RADIUS. Le secret que vous configurez dans Central doit correspondre exactement au secret de la plateforme de 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 secours du Captive Portal sur Autoriser Internet, accordera l'accès sans authentification, ce qui représente un risque de non-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 de commutateur de liaison montante, les AP s'activeront mais les invités n'obtiendront pas d'adresses DHCP. Le quatrième piège est la confiance accordée au certificat lors de la redirection du Captive Portal. Les navigateurs et systèmes d'exploitation modernes appliquent de plus en plus strictement le protocole HTTPS. Le serveur du 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 page de connexion. 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 le même sur les deux flux de firmware. Le chemin de l'interface utilisateur diffère légèrement, mais les objets de configuration sous-jacents restent identiques. 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 d'accès présente un mécanisme de consentement, et le traitement des données de Purple est régi par votre accord de traitement des données avec eux. Pour les établissements 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 de Captive Portal externe, l'authentification RADIUS étant gérée par le service cloud RADIUS de Purple. La configuration réside au niveau du groupe dans Central et se propage à tous les AP du groupe - ce qui constitue la différence architecturale clé 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 établissements Purple. Deuxièmement, obtenez la liste actuelle des domaines autorisés (walled garden) et les détails des points de terminaison RADIUS de Purple sur le portail d'assistance de Purple. Troisièmement, réalisez un 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 relatives au WiFi invité et à la plateforme d'analyse sur purple dot 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 un projet pilote adapté à votre environnement Aruba Central spécifique.