Many customers are requesting Tanaza to support “Captive Portal”. We understood that there is definitely a need to clarify what Captive Portal capability is and how it is implemented in a cloud managed Wi-Fi Network.
We think that the best article that can clarify the relationship between hardware, cloud infrastructure, Radius server, captive portal capability, splash pages, accounting and client management comes from… Meraki!
So… here it is. Enjoy the precision of each single word of this article.
Many organizations have an existing user authentication or directory server that they would like to use to control access to the wireless LAN. Common server types include LDAP or Active Directory. Any type of authentication server with a RADIUS interface can be integrated with a Meraki wireless network. The cloud allows an administrator to configure multiple RADIUS servers for failover.
When an externally hosted RADIUS server is used with either MAC-based access control or WPA2-Enterprise with 802.1x authentication, the cloud managed APs must be able to reach the RADIUS server. The Meraki cloud offers a test tool that enables an administrator to verify connectivity of all of the APs to the RADIUS server, and to check a particular set of user credentials against the RADIUS server. The test tool appears under the Configure tab on the Access Control page.
When an externally hosted RADIUS server is used with sign-on splash page, an administrator can configure the Meraki wireless network to use an externally hosted RADIUS server for user authentication. The Meraki cloud acts as an intermediary in this configuration to provide (1) a consistent end user experience (e.g., the wireless user is not presented with the splash page again if he re-associates to another AP) and (2) RADIUS accounting features.
If the sign-on splash page is hosted by the Meraki cloud, the conversation is a straightforward RADIUS exchange between the Meraki cloud and the external RADIUS server.
If the sign-on splash page is itself externally hosted, the conversation involves exchanges between the splash page server, the Meraki cloud, and the RADIUS server. Specifically:
- The wireless client associates with the Meraki wireless network.
- The user makes an initial request for a URL in his web browser.
- The Meraki AP redirects the user to a URL on the splash page server. (The administrator configures this URL in the Meraki cloud, under the Configure tab on the Splash Page page.) When the Meraki AP redirects the user to the splash page server, it includes the following HTTP parameters in the HTTP redirect:
- continue_url: The URL that the user originally requested. This parameter may be interpreted by the splash page server to decide where the user should be redirected if he authenticates successfully.
- login_url: The URL at the Meraki cloud to which the splash page server should send an HTTP POST with collected user credentials (see Step 4). This parameter is escaped to include the continue_url embedded within it, and should not be interpreted by the splash page server.
- ap_mac: MAC address of the Meraki AP to which the user is associated.
- ap_name: Name (if configured) of the Meraki AP to which the user is associated.
- ap_tags: Tags (if configured) applied to the Meraki AP to which the user is associated.
- mauth: An opaque string used by the Meraki cloud for authentication and security.
- The external splash page server presents the user with a web form that captures the user’s credentials and causes the user to send an HTTP POST to the Meraki cloud, using the URL specified in login_url (see Step 3). In this HTTP POST, the server includes the following parameters:
- username: The username that the wireless user provided to the splash page server.
- password: The password that the wireless user provided to the splash page server.
- success_url (optional): The URL to which the wireless user is redirected if he passes authentication. The splash page server can use this parameter to override the continue_url that the user originally requested.
- The Meraki cloud receives the HTTP POST from the splash page server, and in turn, sends a RADIUS Access-Request to the external RADIUS server with the username and password.
- The RADIUS server processes the RADIUS Access-Request from the Meraki cloud, and responds to the Meraki cloud with a RADIUS Access-Accept or Access-Reject. The RADIUS server may optionally send RADIUS attributes to the Meraki cloud to enforce over the wireless user.
-
The Meraki cloud processes the response from the RADIUS server and redirects the wireless user accordingly.
- If the Meraki cloud receives an Access-Accept message from the RADIUS server, the user has successfully authenticated. The Meraki cloud redirects the user to the original URL he requested (continue_url), or the URL specified by the splash page server in the (optional)success_url (see Step 4).
- If the Meraki cloud receives an Access-Reject message from the RADIUS server, the user has failed authentication and is redirected back to the splash page server’s URL (in Step 3).
Because the Meraki cloud needs to contact an external RADIUS server, the Meraki cloud must be able to reach the RADIUS server. This requirement may necessitate firewall changes that allow inbound connections to the RADIUS server. If the RADIUS server becomes temporarily unavailable, existing wireless clients (already authenticated) remain connected, but new wireless clients are unable to authenticate to access the network.
* * *
Original article available here.
