[auth]
This section contains the options related to authentication.
Declaration
[auth] prompt=Press Enter for push notification or type one-time password: disable_echo=yes
prompt
| Type: | string |
| Required: | no |
| Default: | Press Enter for push notification or type one-time password: |
Description: SPS displays this text to the user in a terminal connection to request an OTP interactively. The text is displayed only if the user uses an OTP-like factor, and does not send the OTP in the connection request.
disable_echo
| Type: | boolean (yes|no) |
| Required: | no |
| Default: | no |
Description: For better security, you can hide the characters (OTP or password) that the user types after the prompt. To hide the characters (replace them with asterisks), set disable_echo to yes.
[connection_limit by=client_ip_gateway_user]
This section contains the options related to limiting parallel sessions.
limit
| Type: | integer |
| Required: | no |
| Default: | 0 |
Description: To limit the number of parallel sessions the gateway user can start from a given client IP address, configure limit. For an unlimited number of sessions, type 0.
[authentication_cache]
This section contains the settings that determine how soon after performing a 2FA/MFA authentication the user must repeat the authentication when opening a new session.
After the first authentication of the user, SPS will not request a new authentication from the user as long as the new authentications happen within soft_timeout seconds from each other. After the hard_timeout expires (measured from the first login of the user), SPS will request a new authentication.
In other words, after opening the first session and authenticating on , the user can keep opening other sessions without having to authenticate again on as long as the time between opening any two sessions is less than soft_timeout, but must authenticate on if hard_timeout expires.
soft_timeout
| Type: | integer [in seconds] |
| Required: | yes, if you want caching |
| Default: | N/A |
| Min value: | 0 |
| Max value: | 2147483647 |
Description: The time in seconds after which the SPS plugin requires a new authentication for the next new session of the user, unless the user successfully authenticates another session within this period.
hard_timeout
| Type: | integer [in seconds] |
| Required: | yes, if you want caching |
| Default: | N/A |
| Min value: | 0 |
| Max value: | 2147483647 |
Description: The time in seconds after which the SPS plugin requires a new authentication for the next new session of the user. The time is measured from the last authentication of the user.
reuse_limit
| Type: | integer [number of] |
| Required: | Optional |
| Default: | 0 |
| Min value: | 0 |
| Max value: | 2147483647 |
Description: The number of times that you can reuse the authentication cache before the SPS plugin requires from you a new authentication for the next session. The default is 0, which means that the authentication cache is not unlimited, but it is turned off.
In the example, if reuse_limit is set to 5, and you successfully authenticated with multi-factor authentication, the next 5 authentications are bypassed in the next 90 seconds (hard_timeout), if there is no gap bigger than 15 seconds (soft_timeout) between the authentications.
If any of the hard_timeout, soft_timeout, or reuse_limit parameters, which operate independently from one another, exceed the configured limit, the SPS plugin requires you to authenticate for the new session.
[WHITELIST]
Having to perform multi-factor authentication to a remote server every time the user opens a session can be tedious and inconvenient for the users, and can impact their productivity. SPS offers the following methods to solve this problem:
-
In SPS, the Connection policy determines the type of authentication required to access a server. If you do not need multi-factor authentication for accessing specific servers, configure your Connection policies accordingly.
-
If the user opens a new session within a short period, they can do so without having to perform multi-factor authentication. After this configurable grace period expires, the user must perform multi-factor authentication to open the next session. For details, see [authentication_cache].
-
The [whitelist source=user_list] and [whitelist source=ldap_server_group] sections allow configuring authentication whitelists and blacklists based on a User List policy or an LDAP Server policy. These two sections are independent, therefore any of the two can be configured and, for example, can create break-glass access for specific users to allow them to bypass authentication.