Automatic authentication via WISPr

Your device provides an interface for authentication via WISPr. The WISPr standard is the technological predecessor of the 802.11u and Hotspot 2.0 specifications. The acronym stands for Wireless Internet Service Provider roaming and designates both a process and a protocol that allow users of WLAN enabled devices to roam seamlessly between the WLANs of different operators – and, therefore, between their Internet service providers. The idea behind it is similar to that of 802.11u and Hotspot 2.0; however, it requires more comprehensive support by the respective users.

Using the WISPr protocol, you can provide logins and network usage on your hotspot in a manner similar to Hotspot 2.0, even for end devices that no longer support Hotspot 2.0. The prerequisite is that your service provider provides the necessary infrastructure. Support for the user's device is provided either by the operating system or a suitable app (smart client). This client handles authentication to the hotspot for the user. If no credentials are available for the relevant network, the client queries the user for valid credentials at the system level. In any case, this eliminates the user having to log in via a login web page in the browser.

Because of its age, almost all current end devices with iOS, Android and Windows 8 support the WISPr protocol. In addition, larger WLAN Internet service providers often have their own apps to make the login for their clients easier: These apps include a preconfigured database of the provider's own hotspots and, optionally, those of their roaming partners. The authentication process corresponds to the following schema:
  1. A customer installs his provider's hotspot app to act as a client, which provides a database of preconfigured hotspot SSIDs.
  2. The client connects automatically with one of the hotspots and sends a HTTP-GET-Request to a random URL to test if direct Internet access is available or the Public Spot requires authentication.
  3. In HTTP-Redirect the hotspot sends a WISPr-XML-Tag with the Login-URL.
  4. The client sends its login data to the Login-URL in an HTTP-Post.
Example for an XML-Tag in redirect:
<HTML> 
<?xml version=”1.0” encoding=”UTF-8”?> 
  <WISPAccessGatewayParam xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” 
   xsi:noNamespaceSchemaLocation=”http://www.acmewisp.com/WISPAccess GatewayParam.xsd”> 
    <Redirect> 
      <AccessProcedure>1.0</AccessProcedure> 
      <AccessLocation>Hotel Contoso Guest Network</AccessLocation> 
      <LocationName>Hotel Contoso</LocationName> 
      <LoginURL>https://captiveportal.com/login</LoginURL> 
      <MessageType>100</MessageType> 
      <ResponseCode>0</ResponseCode> 
    </Redirect> 
   </WISPAccessGatewayParam> 
</HTML>
Note: In order to use WISPr, the device must have an SSL certificate and a private key installed. The certificate must either be signed by a trusted authority or – if it is a self-signed certificate – be imported as a trusted certificate on the client. Otherwise the client will reject the login via WISPr. Further information about loading these objects on your device can be found in the LANCOM techpaper "Certificate Management in Public Spots" available from www.lancom-systems.com.

www.lancom-systems.com

LANCOM Systems GmbH | A Rohde & Schwarz Company | Adenauerstr. 20/B2 | 52146 Wuerselen | Germany | E‑Mail info@lancom.de

LANCOM Logo