[auth]
This section contains the options related to authentication.
[auth] prompt=Hit Enter to send Okta Verify 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 Okta Verify 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 Okta 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 Okta 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 an Okta authentication must the user repeat the authentication when opening a new session.
After the first Okta authentication of the user, SPS will not request a new Okta 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 Okta login of the user), SPS will request a new Okta authentication.
In other words, after opening the first session and authenticating on Okta, the user can keep opening other sessions without having to authenticate again on Okta as long as the time between opening any two sessions is less than soft_timeout, but must authenticate on Okta if hard_timeout expires.
[cache] soft_timeout=15 hard_timeout=90
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 Okta authentication for the next new session of the user, unless the user successfully authenticates another session within this period. Recommended value: 900.
If you want caching, both values are required, and the value of soft_timeout has to be smaller than the value of hard_timeout.
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 Okta authentication for the next new session of the user. The time is measured from the last Okta authentication of the user. Recommended value: 3600.
If you want caching, both values are required, and the value of soft timeout has to be smaller than the value of hard timeout.
[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 Okta.
To look up the Okta username of the user from an LDAP/Active Directory database, configure the [ldap] section of the SPS Okta 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 Okta 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 Okta usernames, see Mapping SPS usernames to Okta 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 Okta 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 Okta usernames, you must configure the SPS Okta plugin to map the gateway usernames to the Okta 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 Okta 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 Okta server.
If you configure both the append_domain parameter and the [ldap] section of the SPS Okta 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 Okta usernames, see Mapping SPS usernames to Okta identities.