[auth]
This section contains the options related to authentication.
[auth] prompt=Hit Enter to send Starling push notification or provide the OTP: whitelist=name-of-a-userlist
prompt
| Type: | string |
| Required: | no |
| Default: | Hit Enter to send push notification or provide the OTP: |
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.
prompt="Hit Enter to send Starling push notification or provide the OTP:"
whitelist
| Type: | string |
| Required: | no |
| Default: | N/A |
Description: The name of a user list containing gateway users configured on SPS (Policies > User Lists). You can use this option to selectively require multi-factor authentication for your users, for example, to create break-glass access for specific users.
-
If you set the Default Policy of the user list to Reject, then the list is a whitelist, so the plugin will not request Starling authentication from the users on the list.
-
If you set the Default Policy of the user list to Accept, then the list is a blacklist, so the plugin will request Starling authentication only from the users on the list.
For details on creating user lists, see "Creating and editing user lists" in the Administration Guide.
[cache]
This section contains the settings that determine how soon after performing a Starling authentication must the user repeat the authentication when opening a new session.
After the first Starling authentication of the user, SPS will not request a new Starling authentication from the user as long as the new authentications would happen within soft_timeout seconds from each other. After the hard_timeout expires (measured from the first Starling login of the user), SPS will request a new Starling authentication.
In other words, after opening the first session and authenticating on Starling, the user can keep opening other sessions without having to authenticate again on Starling as long as the time between opening any two sessions is less than soft_timeout, but must authenticate on Starling if hard_timeout expires.
[cache] soft_timeout=15 hard_timeout=90 conn_limit=5
soft_timeout
| Type: | integer [seconds] |
| Required: | yes, if you want caching |
| Default: | N/A |
Description: The time in seconds after which the SPS plugin requires a new Starling authentication for the next new session of the user, unless the user successfully authenticates another session within this period.
hard_timeout
| Type: | integer [seconds] |
| Required: | yes, if you want caching |
| Default: | N/A |
Description: The time in seconds after which the SPS plugin requires a new Starling authentication for the next new session of the user. The time is measured from the last Starling authentication of the user.
conn_limit
| Type: | integer [number of] |
Description: The cache can be used conn_limit times without multi-factor authentication. If the number of logins exceeds this number, the plugin will request multi-factor authentication again. If this parameter is not set, the number of logins from cache are unlimited.
[ldap]
This section contains the settings you configure when you need to use an LDAP query to map the usernames from your audited sessions to the usernames in Starling.
To look up the Starling username of the user from an LDAP/Active Directory database, configure the [ldap] section of the SPS Starling plugin. Typically, the SPS plugin queries the email address corresponding to the username from your LDAP or Active Directory database. For details on LDAP parameters, see [ldap].
If you configure both the append_domain parameter and the [ldap] section of the SPS Starling plugin, SPS appends the @ character and the value of the append_domain parameter to the value retrieved from the LDAP database.
For other methods of mapping gateway usernames to Starling usernames, see Mapping SPS usernames to Starling identities.
[ldap]
ldap_server_config=<SPS-LDAP-server-policy-name>
filter=(&(cn={})(objectClass=inetOrgPerson))
user_attribute=CN
ldap_server_config
| Type: | string |
| Required: | no |
| Default: | N/A |
Description: The name of a configured LDAP server policy in SPS. For details on configuring LDAP policies, see "Authenticating users to an LDAP server" in the Administration Guide.
filter
| Type: | string |
| Required: | no |
| Default: | (&(cn={})(objectClass=inetOrgPerson)) |
Description: The LDAP filter query that locates the user based on the gateway username. The plugin automatically replaces the {} characters with the gateway username from the session.
filter=(&(cn={})(objectClass=inetOrgPerson))
user_attribute
| Type: | string |
| Required: | no |
| Default: | cn |
Description: The name of the LDAP attribute that contains the Starling username.
[username_transform]
This section contains username transformation-related settings.
[username_transform] append_domain=""
append_domain
| Type: | string (nonrequired, no default) |
| Required: | no |
| Default: | N/A |
Description: If the gateway usernames are different from the Starling usernames, you must configure the SPS Starling plugin to map the gateway usernames to the Starling usernames.
To simply append a string to the gateway username, configure the append_domain parameter. In this case, SPS automatically appends the @ character and the value of this option to the username from the session, and uses the resulting username on the Starling server to authenticate the user. For example, if the domain is set as append_domain: example.com and the username is Example.User, the SPS plugin will look for the user Example.User@example.com on the Starling server.
If you configure both the append_domain parameter and the [ldap] section of the SPS Starling plugin, SPS appends the @ character and the value of the append_domain parameter to the value retrieved from the LDAP database.
For other methods of mapping gateway usernames to Starling usernames, see Mapping SPS usernames to Starling identities.