quarta-feira, 7 de outubro de 2015

Home » , » Meraki - Custom Splash Page Configuration

Meraki - Custom Splash Page Configuration

Julio  outubro 07, 2015  ,   No comments

Configuring a Custom-Hosted Splash Page to work with the Meraki Cloud


Most of Meraki's customers who need a captive portal (UAM) authentication system on their wireless networks use the customizable splash pages that are hosted by Meraki's cloud and configured in Meraki Dashboard.
However some network administrators may prefer to host a captive portal page on their own servers, a feature we refer to as EXCAP. This document describes how to get started plus describes the interface between the captive portal server and the Meraki cloud controller in both click-through and sign-on cases.
Note: This feature is for advanced users and will require the ability to parse GET parameters in order to build a grant or login URL. Knowledge of only HTML is not sufficient, you will also be required to have server-side scripting enabled.



Configuration

This section outlines the configuration in Dashboard necessary to direct new users to your web server hosting a custom splash page.

Configure Access Control

  1. In Dashboard, navigate to Configure > Access control.
  2. Select the SSID you want to configure from the SSID drop-down. 
  3. Under Network access > Association requirements, choose "Open", "WPA2," or "WEP." 
  4. Under Network access > Network sign-on method, choose "Click-through splash page" or "Sign-on splash page." 
  5. Enable walled garden (located under Network access > Walled garden) and enter the public IP address of your web server.
    Note: The address specified needs to be the public-facing IP address of the web server hosting the Splash page, not the local LAN IP. This is because the actual web page request comes from Dashboard, not the local devices.
  6. Click "Save Changes." 

Enabling a Custom-Hosted Splash page on the Meraki Cloud

  1. Navigate to Configure > Splash page
  2. Select the SSID you want to configure from the SSID drop-down.
  3. Under Custom splash URL select the radio button Or provide a URL where users will be redirected:
  4. Type the URL of your custom splash page (ie. http://yourwebsite.com/yourphpscript.php).
  5. Click "Save Changes":

PHP Scripting – Explanation and Theory

This section describes the process by which a user goes through a splash page, including how PHP can be used to provide a custom experience.

Click-through based splash page

  1. When a client connects to your network a web browser is opened with an HTTP-based request (ie.http://google.com).
  2. Assuming you have successfully completed the configuration on the Meraki cloud in the steps above the Meraki access points (AP) in your network will intercept this request and redirect the user through the Meraki cloud to the custom URL you specified. The user should be directed to a URL similar to the following string:
1http://yourwebsite.com/clickthrough....xx:xx:xx:xx:xx
Assuming you have correctly added the web server's IP to the walled garden, the user will be viewing the splash page. Note the extra parameters appended to the URL. It is critical that your web server detects and makes use of these parameters, as they indicate how to grant access. You might choose to store these parameters in a session or otherwise save them for later use.
Note: If your browser enters an infinite redirect loop, check your walled garden settings and ensure the your web server's IP has been added to the walled garden.
  1. At this point you can interact with the user however you wish. You might require them to agree to your terms of service, complete a form, or watch an advertisement. It is important to note that the user can fetch any web content within your walled garden.
  2. Once you are prepared to grant access to the user, you must forward certain parameters you can gather from the URL in step 2 above. Specifically, you must forward the user to the following URL: 
1GET['base_grant_url'] + "?continue_url=" + GET['user_continue_url']
Where the following parameters are extracted from the user’s original query or specified by you:
In order for the ?continue_url parameter to function, the "Where should users go after the splash page" option in Dashboard must be set to "The URL they were trying to fetch."
Depending on the device type, this option is available in the following locations:
  • MR - Wireless > Configure > Splash page > Splash behavior
  • MX - Security appliance > Configure > Splash page > Splash behavior

In the case of the example above the assembled URL would be:
1https://n##.network-auth.com/splash/...p://google.com
Note: Your URL may be different than the above example. It is dynamic and you should therefore never hard-code the grant URL.
  1. The Meraki cloud grants access on the AP and redirects the user to continue to the URL (ie.http://www.google.com).
  2. Advanced: Network operators can optionally specify the length of the session they are granting. To do so include an extra GET parameter with name "duration."
For example:
1GET['base_grant_url'] + "?continue_url=" + GET['user_continue_url'] + "&duration=3600" (to grant access for one hour).

For additional info, please reference our example Clickthrough Splash page code. The script is in its simplest form but it's a working script and can be readily uploaded to your host for testing or use. 

Sign-on based splash page

  1. When a client connects to your network a web browser is opened with a HTTP-based request (ie.http://google.com).
  2. Assuming you have successfully completed the configuration on the Meraki cloud in the steps above the Meraki access points (AP) in your network will intercept this request and redirect the user through the cloud to the custom URL you specified. The user should be directed to a URL similar to the following string:
1http://yourwebsite.com/clickthrough....1&ap_tags=cafe

  1. Assuming you have correctly added the web server's IP address to your walled garden (step I-5), the user will be viewing your splash page (Note the extra parameters appended to the URL). It's critical that your web server detects and makes use of these parameters as they indicate how to grant access. You might choose to store these parameters in a session or otherwise save them for later use.
Note: If your browser enters an infinite redirect loop, check your walled garden settings and ensure your web server's IP was added to the walled garden.

  1. At this point you can interact with the user however you wish. You might require them to agree to your terms of service, complete a form, or watch an advertisement. It is important to note that the user can fetch any web content within your walled garden.
  2. In order to collect logon credentials, you will need to create an HTML based form that collects and then submits these to the login URL. In its simplest form this could look similar to the code below:
01<html>
02    <head>
03        <title>Internet Access Login</title>
04    </head>
05    <body>
06        <h2>Internet Access Login</h2>  
07        <form method=POST action="">
08            <input type="hidden" name="success_url" value="" />
09            Username: <input type ="text" name="username" />
10            Password: <input type ="text" name="password" />
11            <input type="submit" value="Login" />
12        </form>
13    </body>
14</html>

In the above example the code inside is executed via the server-side. The login_url parameter is an opaque string used by the Meraki cloud for authentication and security. It is subject to change and should not be hard-coded.
  1. The user will be prompted (per your custom-hosted page) to enter their credentials and then submit the form to the Meraki cloud.
  2. The Meraki cloud will then send a RADIUS access-request message to the configured RADIUS server which will then receive an Access-accept message (assuming the account is valid and grants access to the AP as appropriate).
  3. In a successful sign-on, the Meraki cloud redirects the user to the provided success URL. For failures the user is redirected to the original captive portal URL. If the RADIUS server responds with an error the user will be presented with the error contained in the "error_message" parameter.  

Forcing a User Back to the Splash Page

If a device should be forced back through the splash, simply clear that device's splash authorization. The AP will then send the client through the splash page the next time it initiates an HTTP flow.


fonte: https://documentation.meraki.com/MR/Splash_Page/Configuring_a_Custom-Hosted_Splash_Page_to_work_with_the_Meraki_Cloud
https://meraki.cisco.com/lib/pdf/meraki_whitepaper_captive_portal.pdf


0 comentários:

Postar um comentário