To optimize the user experience for secured apps, the Blue Cedar Platform provides two mechanisms for controlling when a user must re-authenticate itself during an app session.
The first mechanism is configured via the policy console (user interface or REST API) using the re-authentication settings for the Local App Authentication policy. If enabled, the user must enter their local passphrase or PIN whenever switching between apps, or when the secured app is idle for the configured number of minutes.
The second mechanism is configured from the gateway using the max-session-duration parameter. This parameter sets an absolute time limit ("hard limit") that forces the user to re-authenticate, whether there is any user activity or not with a Blue Cedar-protected app. For more details about the max-session-duration parameter, see "Configuring the user re-authentication settings" section in the Gateway IT Administrator's Guide.
Choose the mechanism for controlling the frequency of user re-authentication based on these rules:
If you want the user re-authentication to be based on the time of user inactivity (idle app), then you must set the gateway's max-session-duration parameter to a larger value than the value set for the re-authentication settings in the Local App Authentication policy.
- Note: If you set the max-session-duration parameter to a smaller value than the Local App Authentication settings, the re-authentication timeout would not take effect because max-session-duration would always timeout before the pass_timeout or vpn_timeout parameter settings would kick in.
- If you want to set a hard limit that a user must re-authenticate (with or without any user inactivity), then set max-session-duration to a smaller value than the re-authentication settings.
- If re-authentication is not enabled via the Local App Authentication policy (or the Local App Authentication policy is not applied to the app), then the gateway's max-session-duration parameter completely controls the user re-authentication process.
The following example illustrates how the console's re-authentication settings and the gateway's max-session-duration parameter can control the frequency of user re-authentications.
In the following scenarios, the console's re-authentication timer was set for 15 minutes, and the gateway's max-session-duration was set for 30 minutes:
If a user is active for 5 minutes and puts his device down for another 15 minutes (for a total elapsed time of 20 minutes), then the console re-authentication setting takes effect and the user must re-authenticate.
If a user is active for 5 minutes, then inactive for 10 minutes, and then active again for 15 minutes (for a total elapsed time of 30 minutes), the gateway's max-session-duration setting takes effect and the user must re-authenticate.