Description
This article explains two portals that FortiAuthenticator offers, captive portal and self-service portal, their purpose, and differences.
Scope
FortiAuthenticator.
Solution
FortiAuthenticator can provide a number of portal services, including captive portal and self-service portal.
These two in particular are sometimes confused; the goal of this Knowledge Base article is to detail the purpose of each one.
1) Self-service portal.
This is an option to allow users to access FortiAuthenticator directly for specific purposes such as:
- Registering themselves.
- Requesting a FortiToken.
- Reporting a lost FortiToken.
- Editing their information in FortiAuthenticator (updating email address/mobile number, etc).
2) Captive Portal.
This is an option to allow users to authenticate; the user would be redirected from the host asking for authentication (such as a FortiGate or Wireless Controller) to FortiAuthenticator, which handles the authentication and upon a successful one sends the user back to the original host.
3) Using Captive Portal vs Self-Service Portal.
Self-service portal is ONLY to be used for users to access FortiAuthenticator directly, to create and edit their accounts. Self-service portal does not handle user authentication for other hosts!
Captive portal handles authenticating users for other hosts, not self-service portal.
In some instances, a captive portal authentication WITH registration is desired (to allow guests to connect and create their own account, for example).
However, this is NOT done via self-service portal.
Captive Portal does also allow for user registration; what options a portal allows (registration, etc) are defined in the actual portal used in a portal policy.
Captive Portal policy:
And the portal:
Self-service policy:
And the portal:
Captive portal workflow steps:
The typical captive portal workflow for an end-user with a FortiGate/FortiWiFi goes as follows:
End-user browser attempts to go through the FortiGate/FortiWiFi to access a website.
(Optional step) FortiGate/FortiWiFi sends a MAC Authentication Bypass (MAB) RADIUS authentication request using the end-user's MAC address to the FortiAuthenticator.
(Optional step) FortiAuthenticator processes the MAB request. It return an Access-Accept response and authorized group name RADIUS attributes if the MAC address is authorized, or an Access-Accept response without the authorized group name RADIUS attribute otherwise.
(Optional step) Upon an Access-Accept response and correct group membership, the end-user browser bypasses the captive portal and is allowed through to the requested website. Workflow stops here.
FortiGate/FortiWiFi intercepts the request and redirects the browser to the FortiAuthenticator's captive portal. The redirect takes the form of an HTTPS request including parameters containing information unique to this particular authentication session. Here is a FortiGate/FortiWiFi redirect sample:
https://192.168.30.47/portal/?post=http://192.168.30.1:1000/fgtauth&magic=040d028c9aaae999&usermac=6...
FortiAuthenticator successfully authenticates the end-user.
FortiAuthenticator redirects the end-user browser to the FortiGate/FortiWiFi's captive portal API specified in the "post" parameter of the original captive portal redirect, e.g. http://192.168.30.1:1000/fgtauth in the above sample. The API call also contains the "magic" parameter (also from the original redirect), in addition to a username and password.
FortiGate/FortiWiFi uses the "magic" parameter to associate the API request to the firewall session that triggered the original redirect and triggers a RADIUS authentication request to the FortiAuthenticator using the username and password from the API request.
FortiAuthenticator verifies the credentials from the RADIUS authentication request. If valid, it returns a RADIUS Access-Accept response containing the appropriate RADIUS attributes.
FortiGate/FortiWiFi redirects the end-user browser to a website. The specific website depends on the FortiGate/FortiWiFi configuration.
