The open HTTP API enables Wimark solutions to easily integrate with any third-party authentication portal.
This allows customers to choose the most attractive portal solutions available on the market, and developers of Wi-Fi services to offer their services across an extended list of access points and enhance the authentication service with targeted advertising by analyzing MAC addresses within the area covered by the Wimark-managed network.
This allows customers to choose the most attractive portal solutions available on the market, and developers of Wi-Fi services to offer their services across an extended list of access points and enhance the authentication service with targeted advertising by analyzing MAC addresses within the area covered by the Wimark-managed network.
Compliance with Legislative Requirements
According to the latest legislative initiatives of the Russian Federation, every user of a public Wi-Fi network must be identified. The main tool for ensuring user authentication and authorization is the authentication portal.
In the list of solutions we have developed, the functionality of the authentication portal is found in two products - Virtual Access Point (vAP) and AAA-server. Let's consider the implementation of the portal in each of these products.
Authorization Function on the Wimark Platform
vAP - a virtual access point - is software installed on a physical device. Like everything in the cloud management paradigm, vAP consists of two parts: agent software at the access point and services interacting with the agent, located on a server in the cloud. The portal functionality in the vAP product is implemented, to a greater extent, in the cloud, however, the operating principle is intrinsically linked with the agent software at the access point.
Technically, authorization and authentication on the portal consist of several phases: connection, redirection to the portal, authentication and authorization, and organization of internet access. Let's examine each stage separately.
Connection - the phase during which the wireless network client (mobile phone, tablet, or any other device with a Wi-Fi module) connects to the Wi-Fi network (turns on the adapter and selects the SSID to connect to). After a series of 802.11 standard message exchanges between the client terminal and the access point, the device connects to the wireless network and receives an IP address.
Redirection to the portal - the phase following connection. The user, using a device connecting to the Wi-Fi network, visits any resource on the internet. Technically, the user terminal makes an HTTP request to the server where the requested resource is located. However, a set of rules transferred by the management platform to the access point with vAP software does not allow data packets transmitted from the connected unauthorized device to reach the requested resource. The access point intercepts these packets and responds to the user's request. In the HTTP response, the access point informs the client terminal that the resource has temporarily moved to another server with a different address. This other server is the authentication portal. Thus, after a series of HTTP redirections, the user lands on the authentication portal and sees its welcome page in their browser. At the moment of redirection, the access point modifies the user's HTTP request and adds typical parameters needed for identification on the portal (MAC address of the client device, MAC address of the access point, etc.). Thus, the authentication portal receives information about the connected user.
Authentication and authorization - the stage of the process during which the user validates their access attributes (login, password). To clarify the sequence of actions on the authentication portal, it makes sense to describe the main elements of the portal's user interface.
The user interface can be divided into several parts:
When redirected to the authentication portal, the user sees a login and password form in their browser. The actual presentation of the login and password form depends on the type of authorization used on the portal. Usually, public Wi-Fi networks offer authorization via SMS. This is also due to Russian legislation, as the combination of "device MAC address - user's phone" serves as a unique identifier, by which one can unequivocally determine who and at what time gained access to the public network.
In the case of SMS authorization, the user enters their phone number in the login and password form field and waits for an SMS with an authorization code. The SMS is sent from the portal via the API of an external SMS gateway.
The user enters the received code in the verification code field in the login-password form.
Next, in the typical scenario of the authorization portal, the user is shown advertising content in either a dynamic or static form on their browser screen. After that, the user is granted internet access by navigating to a pre-configured internet resource address.
From a technical interaction perspective, redirecting the user to the internet occurs through the interaction of the platform's API and the authentication portal. The portal commands the platform that the user (client terminal) has been authorized and that the access rules for them need to be changed. The platform, in turn, relays this message to the access point to which the terminal is connected. The access point applies the rule and through the platform informs the portal about it.
The visual components of the portal, marketing content, and type of authorization can be changed; for this, Wimark provides documentation describing typical capabilities for altering the appearance of the authentication portal.
The platform's HTTP API, together with the RADIUS API, allow for integration with any external authentication portal.
According to the latest legislative initiatives of the Russian Federation, every user of a public Wi-Fi network must be identified. The main tool for ensuring user authentication and authorization is the authentication portal.
In the list of solutions we have developed, the functionality of the authentication portal is found in two products - Virtual Access Point (vAP) and AAA-server. Let's consider the implementation of the portal in each of these products.
Authorization Function on the Wimark Platform
vAP - a virtual access point - is software installed on a physical device. Like everything in the cloud management paradigm, vAP consists of two parts: agent software at the access point and services interacting with the agent, located on a server in the cloud. The portal functionality in the vAP product is implemented, to a greater extent, in the cloud, however, the operating principle is intrinsically linked with the agent software at the access point.
Technically, authorization and authentication on the portal consist of several phases: connection, redirection to the portal, authentication and authorization, and organization of internet access. Let's examine each stage separately.
Connection - the phase during which the wireless network client (mobile phone, tablet, or any other device with a Wi-Fi module) connects to the Wi-Fi network (turns on the adapter and selects the SSID to connect to). After a series of 802.11 standard message exchanges between the client terminal and the access point, the device connects to the wireless network and receives an IP address.
Redirection to the portal - the phase following connection. The user, using a device connecting to the Wi-Fi network, visits any resource on the internet. Technically, the user terminal makes an HTTP request to the server where the requested resource is located. However, a set of rules transferred by the management platform to the access point with vAP software does not allow data packets transmitted from the connected unauthorized device to reach the requested resource. The access point intercepts these packets and responds to the user's request. In the HTTP response, the access point informs the client terminal that the resource has temporarily moved to another server with a different address. This other server is the authentication portal. Thus, after a series of HTTP redirections, the user lands on the authentication portal and sees its welcome page in their browser. At the moment of redirection, the access point modifies the user's HTTP request and adds typical parameters needed for identification on the portal (MAC address of the client device, MAC address of the access point, etc.). Thus, the authentication portal receives information about the connected user.
Authentication and authorization - the stage of the process during which the user validates their access attributes (login, password). To clarify the sequence of actions on the authentication portal, it makes sense to describe the main elements of the portal's user interface.
The user interface can be divided into several parts:
- Login and password form
- Form for static and dynamic advertising
- "Switching access"
When redirected to the authentication portal, the user sees a login and password form in their browser. The actual presentation of the login and password form depends on the type of authorization used on the portal. Usually, public Wi-Fi networks offer authorization via SMS. This is also due to Russian legislation, as the combination of "device MAC address - user's phone" serves as a unique identifier, by which one can unequivocally determine who and at what time gained access to the public network.
In the case of SMS authorization, the user enters their phone number in the login and password form field and waits for an SMS with an authorization code. The SMS is sent from the portal via the API of an external SMS gateway.
The user enters the received code in the verification code field in the login-password form.
Next, in the typical scenario of the authorization portal, the user is shown advertising content in either a dynamic or static form on their browser screen. After that, the user is granted internet access by navigating to a pre-configured internet resource address.
From a technical interaction perspective, redirecting the user to the internet occurs through the interaction of the platform's API and the authentication portal. The portal commands the platform that the user (client terminal) has been authorized and that the access rules for them need to be changed. The platform, in turn, relays this message to the access point to which the terminal is connected. The access point applies the rule and through the platform informs the portal about it.
The visual components of the portal, marketing content, and type of authorization can be changed; for this, Wimark provides documentation describing typical capabilities for altering the appearance of the authentication portal.
The platform's HTTP API, together with the RADIUS API, allow for integration with any external authentication portal.
Integration of the Authentication Portal with Wimark's AAA Server
The functionality of the portal in terms of AAA complements the AAA solution with a user frontend for authorization in public Wi-Fi networks. The usage scenario is similar to the one described above, however, it's worth noting that AAA is a separate product and can be used independently from the Wi-Fi network management platform.
AAA terminates RADIUS requests from Wi-Fi controllers or management platforms. HTTP traffic, as in the case of vAP, is processed by the frontend of the authentication portal. Further interaction of the portal with the controller or Wi-Fi management platform occurs through integration with AAA via the RADIUS protocol.
Like all Wimark products, AAA has an open HTTP API and can be integrated with any authentication portal, carrying backend functionality and integration with the Wi-Fi infrastructure.
The functionality of the portal in terms of AAA complements the AAA solution with a user frontend for authorization in public Wi-Fi networks. The usage scenario is similar to the one described above, however, it's worth noting that AAA is a separate product and can be used independently from the Wi-Fi network management platform.
AAA terminates RADIUS requests from Wi-Fi controllers or management platforms. HTTP traffic, as in the case of vAP, is processed by the frontend of the authentication portal. Further interaction of the portal with the controller or Wi-Fi management platform occurs through integration with AAA via the RADIUS protocol.
Like all Wimark products, AAA has an open HTTP API and can be integrated with any authentication portal, carrying backend functionality and integration with the Wi-Fi infrastructure.
The typical usage scenarios for portal-vAP and portal-AAA combinations differ. The portal-vAP combination works exclusively with the Wimark management platform. The functionality of the portal becomes integrated into the platform, which offers an advantage in terms of the speed of service deployment, however, it limits its application to infrastructure with Wimark software only. On the other hand, the portal-AAA combination is maximally independent of the type of Wi-Fi infrastructure and allows for the deployment of the authorization service on any Wi-Fi network.