Cisco Meraki
Cisco Meraki is the one integration path where Sign In needs no equipment at the site. There is no Service Gateway to install: the Meraki access points authenticate against the platform over RADIUS, and the captive portal is served from the cloud.
Both deployment types use plain RADIUS with a splash page in front of the guest. Neither uses the Meraki Dashboard API, and neither uses RadSec.
Two deployment types
Section titled “Two deployment types”The integration is configured as one of two types, chosen per Sign-In context. They differ in how the guest reaches the portal and in what Meraki has to be told.
| MAC-based Access Control | Splash Page via RADIUS Server | |
|---|---|---|
| Meraki setting | MAC-based access control | Sign-on with my RADIUS server |
| How the guest arrives | Meraki authenticates the device by MAC against the platform, and the guest lands on a Cisco ISE-style splash page | Meraki redirects to a Custom Splash URL pointing at the platform |
| Change of Authorization | Not used | Used, to move the session to its granted access after sign-in |
| Encrypted SSID | Optional Managed Pre-Shared Key, giving the SSID a venue-wide key | Not applicable |
| Suits | The shorter path, and venues that want the SSID encrypted | Venues that want the portal experience driven from the platform, including Meraki MX deployments |
For the Splash Page type, the platform also asks how the venue is built: only Meraki access points, only Meraki MX security appliances, or a mixed deployment with both. The answer changes what has to be configured in the Meraki Dashboard.
MAC authentication for devices without a user
Section titled “MAC authentication for devices without a user”MAC-based Access Control is not only a guest path. A device’s MAC address can be associated with a policy in the platform so it is authenticated with no user interaction at all, which is what IoT equipment, printers and other headless gear need. The same RADIUS integration carries it, so a venue does not need a second SSID or a second integration for its devices.
What the network needs
Section titled “What the network needs”| Item | Requirement |
|---|---|
| Meraki organisation | Admin access to the Meraki network Sign In will serve, and at least one SSID available for guest traffic |
| Hardware | MR-series access points, plus Meraki MX security appliances where the deployment includes them |
| RADIUS | Reachability from Meraki to the platform’s RADIUS authentication and accounting endpoints, with the context’s RADIUS client secret |
| Walled garden | The captive portal address ranges allowed through before the guest has signed in |
| Context setting | The Sign-In context’s network integration set to Cisco Meraki, either when the context is created or afterwards |
What this integration is not
Section titled “What this integration is not”It does not use the Meraki Dashboard API, so it is not the same mechanism as EasyPSK for Cisco Networks in its Wireless Personal Network form, which does.
It does not use RadSec. The RADIUS path is plain RADIUS, and where a private path is required it runs over a Service Connector rather than over the public internet.
It does not place equipment at the site. If the venue needs local DHCP, DNS or routing served by the integration, that is the Cisco Service Gateway path instead.
Related
Section titled “Related”- Implement the service: the other integration paths, with a topology for each.
- Captive portal: what the guest sees, including captive-portal detection and DHCP Option 114.
- Login modules: the sign-in methods available on the portal.