The HotSpot feature allows you to redirect non-authenticated users to a splash screen that allows them to establish a session.
It works for both users connected to the Active Directory and users outside the Active DirectoryThis Article is for the 4.30 LTS, for a 4.40/4.50 please refer to this article
¶ Installing the Hotspot feature
- On the left menu click on Your system / features.
- On the search field, type "HotSpot"
- Click on Install button under the Web portal authentication (HotSpot)
¶ Create your authentication page.
- On the left menu, select "Web services" / services
- Click on the Button "New service"
Select the option, Create a portal authentication page and give a name of your web service
- Select your new Web service on the table.
- Select Server names tab.
- Give a virtual host name to reach the Web site, it can be "*" for all urls or a server name or the IP address of the server.
- Click on Apply.
- Choose "Ports" tab
- Click on New Entry
- On the Listen Port, type 80 and click on Add button
- Close the layer
- On the main table click on the second icon to put the service in production mode.
¶ Configure the HotSpot system.
- On the left menu, go to "Web portal authentication" and use the "General settings" tab
¶ Parameters
- Set the URL of the defined web service into the "Authentication Page Address"
- Select the Template that will be used to generate the Authentication page design.
- Debug: Turn the authenticator and the Web authentication page in debug mode.
- HTTP Lost landing page: After establishing the session, Artica will try to get the initial user request.
Sometimes, requests as been made by the browser or the operating itself.
These URLs will be lost during the authentication process. Set here the URL displayed in this case. ( eg http://www.bing.com ) - Landing page: If set, the user will be automatically redirected to this Web page after being authenticated. (it overwrite the HTTP Lost landing page value).
¶ Performance: Service
this section defines the Proxy behavior when using the HotSpot Plugin.
In order to not delay the session process, the proxy is able to load “Processes” a Process is an HotSpot Plugin.
The HotSpot Plugin is in charge to deny or allow a request, understand that a request is not a session, in single page, you can have images, css, embeeded objects…
Each object in a web page is a request: css, images, embeeded objects…
A process is not a session, an HotSpot plugin can handle many requests but only one at the same time.
The “Max Processes to run” can be calculated about “How many requests can handle the proxy at the same time”.
We estimate in a standard utilization a performance of 20 requests per second (according to the Positive Cache TTL value)…
The default is a bit higher.. So it can handle about 50 requests per seconds.
Processes to Start: How many HotSpot Plugins are loaded when the proxy service is started.
Processes to prepare: In order to reducing latency of executing a new process, the proxy “prepare” one or several processes.
These processes are not used but prepared to be used if the proxy require more HotSpot processes.
Positive Cache TTL: The proxy ask to the HotSpot plugin using a key/pair cache index.
When the HotSpot plugin send a positive result, the proxy stores this result in a memory cache.
In this case, the second request will not sent to the HotSpot plugin but get results from the first request.
Each key/pair have a limited period in a cache defined by this token.
It means that an HotSpot Session have a minimal period defined by this cache ( 5 minutes by default )
Negative Cache TTL: This is the same behavior of “Positive Cache” but when the HotSpot plugin return a wrong result ( session expired, authentication failed, ban…).
By default, this cache is disabled (0) in order to allow the user to retry authentication just after a wrong posted credential.
¶ TimeOuts Sessions
TimeOuts sessions are an HotSpot session/member time to live.
- Re-authenticate each: Terminate the surf and ask again to the user to authenticate again.
- Disable account after: The login account is stored in the HotSpot database and is flagged to “disabled”, the user cannot authenticate/use the HotSpot definitively.
- Remove account after: Destroy the login account in the HotSpot database. The user can retry the authentication and use the Web service again.
¶ Authentication
Authentication section allows you to define which database can be used to verify accounts, you have 2 databases ;
Active Directory: Artica use the Active Directory LDAP database if posted credentials are stored in the Active Directory.
You have to install the Active Directory feature and configure “Connections” to let Artica know where to test posted credentials.
Use Voucher method: The Voucher method use username and password with the Artica local database, with vouchers, you can use tickets or username to authenticate members.