Aruba Central and Purple WiFi: क्लाउड-व्यवस्थापित एकत्रीकरण

Aruba Central and Purple WiFi: Cloud-Managed Integration. A briefing for IT leaders. Welcome. If you're managing guest WiFi across multiple venues and you're running Aruba Central, this episode is directly relevant to you. I'm going to walk you through exactly how Purple integrates with Aruba Central — the architecture, the configuration steps, the multi-site rollout patterns, and the pitfalls that catch teams out. This is a practical briefing, not a product pitch. Let's get into it. Section one: Context and why this matters. Aruba Central is HPE's cloud-managed networking platform. It's the control plane for tens of thousands of Aruba Instant Access Points deployed in hotels, retail chains, stadiums, conference centres, and public-sector buildings. If you've moved from on-premises Aruba controllers — the Mobility Controllers or Mobility Conductors — to Central, you've already experienced the shift from CLI-heavy, site-specific configuration to group-based, cloud-pushed policy management. That shift fundamentally changes how you integrate a guest WiFi platform like Purple. On a traditional on-prem Aruba controller, you'd configure captive portal redirect and RADIUS authentication directly on the controller itself. The controller was the policy enforcement point, and it sat in your data centre or comms room. With Aruba Central, the policy enforcement still happens at the Access Point — but the configuration is pushed down from the cloud. That means your integration touchpoints are different. You're working with group templates, SSID profiles, and external captive portal profile objects that live in Central's configuration hierarchy, not on a box in a rack. Purple sits above all of this as a cloud-hosted guest WiFi intelligence platform. It provides the captive portal — the splash page that guests see — it handles the authentication logic, it captures first-party data with consent, and it feeds analytics back to your marketing and operations teams. The question is: how do you wire these two cloud platforms together cleanly, at scale, across potentially hundreds of sites? Section two: The technical architecture. Let me describe the data flow when a guest connects. A guest device associates with your guest SSID — let's call it Hotel-Guest — which is broadcast by an Aruba Instant AP. The AP has been configured, via Aruba Central, with an External Captive Portal profile. That profile contains two critical pieces of information: the redirect URL, which points to Purple's captive portal server, and the RADIUS server details, which point to Purple's RADIUS-as-a-Service endpoint. When the guest opens a browser, the AP intercepts the HTTP request and redirects it to Purple's splash page. The guest authenticates — via social login, email, SMS, or a custom form, depending on your Purple configuration. Purple's backend then sends a RADIUS Access-Accept message back to the AP, which grants the guest internet access and moves them from the pre-authentication role to the authenticated guest role. RADIUS accounting packets flow throughout the session, giving Purple visibility into session duration and data usage. Now, the key difference from on-prem Aruba: in Aruba Central, you configure the External Captive Portal profile once, at the group level, and it propagates to every AP in that group. You don't touch individual APs. This is enormously powerful for multi-site deployments, but it requires you to get the group structure right before you start. Aruba Central organises devices into Groups, and within groups, you can have Sites. A Group is the unit of configuration — SSIDs, radio profiles, security policies all live at the group level. Sites are the unit of location and monitoring. For a hotel chain, a sensible structure is one group per property type — say, Full-Service Hotels and Budget Properties — with each physical hotel as a separate site within the appropriate group. Purple's configuration then maps to groups: one External Captive Portal profile per group, pointing to the same Purple RADIUS endpoint, but potentially with different splash page themes per site using Purple's venue-level customisation. The walled garden is a critical configuration element that teams frequently get wrong. Before a guest authenticates, the AP only allows DNS and DHCP traffic, plus any domains you explicitly whitelist. For Purple to function, you must whitelist Purple's captive portal domain, any CDN domains Purple uses for assets, and any social login provider domains if you're using social authentication — Facebook, Google, Apple. If you miss a domain, the splash page will partially load or authentication will silently fail. Purple's support documentation provides the current walled garden list, and it's worth treating that list as a living document that you review whenever Purple updates their platform. Section three: Aruba Central API surface for automation. If you're rolling out to more than about twenty sites, manual configuration through the Central UI becomes a bottleneck. Aruba Central exposes a comprehensive REST API — the Central API — that lets you automate SSID creation, captive portal profile assignment, and walled garden configuration. The API is OAuth 2.0 authenticated, and you'll need to generate API credentials from the Central portal. The key API endpoints for a Purple integration are: the WLAN configuration endpoint, which lets you create and update SSID profiles; the external captive portal profile endpoint, which is where you define the Purple redirect URL and RADIUS server details; and the site and group management endpoints, which let you assign devices to sites and groups programmatically. If you're onboarding a new venue, you can write a script that creates the site in Central, assigns the APs to the site, applies the correct group template, and configures the Purple-specific captive portal profile — all without touching the UI. Purple also exposes its own API, which lets you create venue records, configure splash page themes, and pull analytics data. A mature integration will use both APIs together: Central's API to manage the network layer, Purple's API to manage the guest experience layer. This is the pattern that large retail chains and hotel groups use when they're onboarding dozens of new sites per quarter. Section four: Step-by-step configuration. Let me walk you through the configuration sequence for a single site, which you'd then automate for scale. First, in Aruba Central, navigate to your target group and open the WLAN configuration. Create a new SSID — for example, Venue-Guest — and set the security level to Visitors. This is Aruba's terminology for an open or captive-portal-authenticated network. Second, under the Security tab, set the Splash Page type to External Captive Portal. Create a new External Captive Portal profile. Give it a descriptive name — Purple-Guest-Portal works well. Set the Authentication Type to RADIUS Authentication. Enter Purple's captive portal server hostname in the IP or Hostname field. Enter the redirect URL. Enable HTTPS. Set the Captive Portal Failure behaviour to Deny Internet, which is the more secure default. Third, configure the RADIUS server. In Central, go to the authentication server settings and add Purple's RADIUS-as-a-Service server. You'll need the server IP or hostname, the shared secret — which you generate in Purple's platform — and the authentication port, which is standard 1812, with accounting on 1813. Add this server as the Primary Server for your guest SSID. Fourth, configure the walled garden. In the SSID's access rules, add the Purple captive portal domain and any social login domains to the allowlist. Test this carefully — a missing domain is the most common cause of splash page failures. Fifth, save and push the configuration. Central will push the configuration to all APs in the group. Verify on a test device that the redirect fires correctly and that authentication completes. Section five: Multi-site rollout patterns. For a deployment across fifty or more sites, you need a disciplined approach. The pattern I recommend is: pilot, template, automate, validate. Pilot on a single site. Get the configuration exactly right — walled garden complete, RADIUS working, splash page loading cleanly, accounting flowing. Document every parameter value. Then build that configuration into a Central group template. The template becomes your source of truth. For the rollout, use the Central API to push the template to new groups as you onboard sites. If your Purple deployment uses different splash page themes per brand or region, parameterise the captive portal profile — the redirect URL can include query parameters that Purple uses to serve the correct theme. This means you can have a single RADIUS endpoint but multiple splash page experiences, all managed centrally. Validate each site after onboarding. A simple validation script that associates a test device, checks for the redirect, authenticates, and verifies internet access will catch configuration drift before guests experience it. Purple's analytics dashboard will also show you whether sessions are being recorded — if a site goes dark in Purple's reporting, that's your signal that something's broken at the network layer. Section six: Implementation pitfalls. The walled garden is the number one failure point. Test with a device that has no cached DNS or portal sessions. Use a fresh browser profile or incognito mode. The second pitfall is RADIUS shared secret mismatch. The secret you configure in Central must exactly match the secret in Purple's platform. A single character difference will cause silent authentication failures — the AP will receive no response from the RADIUS server and will either deny the guest or, if you've set the captive portal failure mode to Allow Internet, grant access without authentication, which is a compliance risk. The third pitfall is VLAN misconfiguration. Guest traffic should be on a dedicated VLAN, isolated from your corporate network. In Aruba Central, this is configured in the VLAN settings of the SSID profile. If your guest VLAN isn't correctly trunked on the uplink switch port, APs will come up but guests won't get DHCP addresses. The fourth pitfall is certificate trust on the captive portal redirect. Modern browsers and operating systems are increasingly aggressive about HTTPS enforcement. Purple's captive portal server uses a valid TLS certificate, but if your walled garden blocks the OCSP or CRL endpoints that the client uses to validate the certificate, you'll see certificate errors on the splash page. Add those endpoints to your walled garden. Section seven: Rapid-fire questions. Does Purple work with Aruba Central's AOS-10 architecture as well as AOS-8? Yes. The external captive portal mechanism is consistent across both firmware streams. The UI path differs slightly, but the underlying configuration objects are the same. Can I use Purple's RADIUS-as-a-Service without running my own RADIUS infrastructure? Yes, that's the point. Purple's RADIUS-as-a-Service is a cloud-hosted RADIUS server that you point your Aruba APs at. You don't need FreeRADIUS or Cisco ISE on-premises. Does this integration support WPA3? Aruba Central supports WPA3 on compatible APs, and you can enable WPA3 transition mode on your guest SSID. Purple's captive portal mechanism is agnostic to the encryption layer — it operates at the HTTP redirect level, not the 802.11 association level. Is the data Purple collects GDPR-compliant? Purple is designed with GDPR compliance as a core requirement. The splash page presents a consent mechanism, and Purple's data processing is governed by your data processing agreement with them. For EU venues, ensure your Purple configuration includes the appropriate consent language and that your DPA is in place before go-live. Section eight: Summary and next steps. To summarise: Aruba Central and Purple integrate via the External Captive Portal mechanism, with RADIUS authentication handled by Purple's cloud RADIUS service. The configuration lives at the group level in Central and propagates to all APs in the group — which is the key architectural difference from on-premises Aruba. For multi-site rollouts, use the Central API to automate provisioning and treat your pilot site configuration as the template for everything that follows. Your immediate next steps: first, confirm your Aruba Central group structure maps to your Purple venue hierarchy. Second, obtain Purple's current walled garden domain list and RADIUS endpoint details from Purple's support portal. Third, run a pilot on a single site and validate the full authentication flow before scaling. Fourth, build your automation scripts using the Central API and Purple API in parallel. If you're evaluating Purple for the first time, the guest WiFi and analytics platform pages on purple dot ai give you a clear picture of what you're getting beyond the captive portal — the first-party data capture, the marketing automation, the footfall analytics. That's the business case that gets this project funded. Thanks for listening. If you have questions about this integration, Purple's solutions team can walk you through a proof-of-concept scoped to your specific Aruba Central environment.