How it Works¶
Here is the description of how the Captive Portal works internally, which might be of interest to the Administrators. From now on we will assume the selected backend is Active Directory, deployed on-premises.
Let us assume the user would like to visit https://google.com and he types this URL in the browser’s address bar. The browser knows it must use the proxy server to access the internet so it sends the request to the proxy.
Proxy server is configured to require Captive Portal authentication, so it responds with
511 Network Authentication Requiredmessage, specifying the
https://ip_address_or_fqdn_of_proxy/portal/loginURL as the address to login to.
Browser navigates to that address and renders that page. This page contains user name and password fields to be filled. User fills in these fields and clicks the Login button. Browser sends the credentials to the portal (which is located on the proxy box too - just where Admin UI is located, on port 443).
Portal code verifies the credentials by doing a simple bind to the LDAP server configured by the Administrator. If credentials are correct, session information is written to the
/opt/websafety-ui/var/db/portalfolder database and success page is sent to the browser.
Browser renders the success page; user sees he is logged on successfully on the proxy and continues browsing.
Any new connection from the user is looked up in the session database and user name from the database is used as authenticated user name.
Each user is supposed to be using a different IP address. If one IP address is shared by different users constant re-authentication or incorrect user to IP session info may occur.
Clustering of proxy nodes is not possible as each node would contain its own copy of the session database.
This type of authentication works best when there is a human in front of the display screen to type the credentials into login page. If for example, it is the network service which runs behind the proxy - Captive Portal authentication may not be a good choice.