Applying Authentication Systems to Captive Portals and Devices
How to apply authentication systems and network policies to captive portals and Sputnik-powered devices.
Overview of network policy order: device, captive portal, authentication system.
When a client access a Sputnik-powered AP or gateway device, they encounter a series of authentication systems and network policies, in the following order. Understanding this order will help you to decide whether an authentication system or network policy should be applied to a captive portal or directly to a device.
First, the end user client associates with a Sputnik-powered Wi-Fi device. Device override policies will apply. Therefore, apply authentication systems that you want to take effect before the captive portal is shown directly to the device (that is how authentication by MAC address works).
Second, the client will encounter a captive portal. Captive portal overrides and authentication systems are applied now. Therefore, apply authentication systems that you want to appear in the captive portal directly to it. Also, apply any network policies that you want to take effect after viewing the captive portal but before authentication, such as walled gardens.
Finally, the client will authenticate through one of the authentication systems that you've applied to the captive portal. After they've done that, they may be restricted by various network policies that you have defined, such as "content filtering" or "block private nets". Therefore, these network policies should be applied directly to authentication systems.
Apply user authentication systems to captive portals.
Apply device authentication systems directly to Sputnik-powered devices.
Apply walled garden policies to captive portals.
Apply deny/reject and destination NAT policies to authentication systems.
In most cases, it makes sense to apply network policies after authentication (with walled gardens being the obvious exception). In other words, there is no reason to apply "block private nets" or "content filtering" policies before a user gains access to the Internet. Therefore it's best to apply non-walled garden network policies directly to authentication systems (or to groups within the authentication system).