[Enable session state]
Select to enable session state. With HTML Login Forms, session state is required. With Basic Authentication session state is required on if Concurrent Accesses Control is enabled.
[Inactivity Time-out delay]
Specify here the inactivity delay after which the session will time-out.
[Deny access on Time-out]
Select to deny access to an user if the inactivity time-out delay is reached.
With HTML Login forms:
- Withen this option ENABLED, access to all queries attached to the session
in question will be denied as expected. Please note that this behavior also
apply to request for unprotected resource. To view an unprotected resource
with a browser owning a timed out session, the user should restart a new
session (by retyping her/his login/password) or detach the timed out session
from the browser (validate a login form with empty login/password fields). It
is NOT recommended to DISABLE this option to grant access to unprotected
resource for timed out session. This is because it may generate unexpected
behaviors.
- With this option DISABLED, access to all queries attached to the session in question may be granted or denied depending session entry availability. By default timed out session are cleaned up every 15 minutes. If the session entry is found access is granted and the inactivity counter is reset (since version 5.0b10), if the session entry no longer exists access is denied. The only case where it is safe to DISABLE this option is to use Concurrent Accesses Control with session not based on Ticket IDs. For sessions based on the client IP address the browser will remain bound to the timed out session and access will be denied until the session entry is cleaned up.
With Basic Authentication:
With basic Authentication, this
option must be DISABLED. Since the filter cannot reset the Authorization
header, the browser will remain bound to the timed out session and access will
be denied until the session entry is cleaned up.
[Hit count maximum]
Specify here the maximum number of hit allowed per user session (0=unlimited). If this value is reached access is denied. However, the user main re-login to access the protected area.
To query an Url when the hit count maximum is reached use [Session error internal notification] option located under tab [Advanced] in the Security Handler properties.
[Session list size]
Specify here the maximum number of sessions to be handled simultaneously.
Session ID Internal structure
When a user logs-in the User Database affects a session (identified by a session ID) to this user. Session IDs are used to identify user sessions for each incoming HTTP requests. Session IDs remain constant during a session live (from the log-in to the log off (active or by time out). Different sessions IDs may refer the same login.
A session ID must be unique and is build using one or several datas. This frame is used to define how the User Database will build session IDs.
Scenario 1: Custom unique ID generated by the user database (Ticket ID)
The most convient is to base the session ID on a unique identifier generated by the User Database (the Ticket ID). To be operational, this unique ID must be provided by the browser with each request submitted. Unfortunately, HTTP protocol does not implement a universally reliable feature for the browser to accept and return an unique identifier. DAF offers two solutions to handle a unique identifier: via a cookie or via a string inserted in the Url (for more information refer to Security Handler settings).
For this scenario:
- Check [Ticket ID]
- Check [Create if missing]
- Check [Ignore other properties if ticket ID is found]
- Uncheck other settings in this frame
- Configure the Security Handler to use Tickets IDs
Scenario 2: Client IP Address
Another solution to build an Session ID consist in using the client IP address. Unfortunately, this solution is not very reliable because often an IP address does not identify a unique user. Users located behind a firewall or a proxy will use the same client IP address. A the opposite, a unique user may use different client IP address (dial-up Internet access and AOL clients). In this case, a unique user is seen as several different users. To help you may use the browser User Agent to build the session ID. This way, two users located behind a same firewall but using different browsers will be seen as different.
For this scenario:
- Uncheck [Ticket ID]
- Uncheck [Create if missing]
- Uncheck [Ignore other properties if ticket ID is found]
- Check [Client IP Address]
- Check [User Agent] (optional)
Single Sign-on settings
These options allow to setup "single sign on" among a server pool. With this feature, a user may authenticate on one server and surf to another server without the need to re-authenticate. Users credentials are transparently transfered from one server to the other.