Notable features
This section contains the notable features of this plugin.
-
To map the gateway usernames to the
-
The [WHITELIST] section allows configuring authentication whitelists and blacklists for example to create break-glass access for specific users to allow them to bypass
-
The [authentication_cache] section contains the settings that determine how soon after performing a
-
The [connection_limit by=client_ip_gateway_user] section contains the options related to limiting parallel sessions.
Configure your Okta account for SPS
Prerequisites:
-
Administrator access to your Okta account.
-
Make sure that you have all the required components listed in Technical requirements.
-
Add users to your Okta account.
The users you want to authenticate with SPS must have an activated account in Okta. Navigate to Directory > People, and add or import your users. For details, see A Quick Look at Adding People in the Okta documentation.
-
Enable Multifactor Authentication (MFA) for your organization.
Optionally, you can create a Multifactor Policy in Okta to enable MFA only for the group of users who you want to authenticate with SPS.
When selecting the accepted factor types for your users, make sure to select at least one factor that SPS supports.
For details, see Multifactor Authentication in the Okta documentation.
-
Create an API token.
Navigate to Admin > API > Tokens, click Create Token, and save it.
Configure SPS to use Okta multi-factor authentication
Prerequisites:
-
Your Okta API token.
Caution: According to the current Okta policies, your API token expires if it is not used for 30 days. Make sure that you use it regularly, because SPS will reject your sessions if the API token is expired.
-
Administrator access to SPS.
-
Make sure that you have all the required components listed in Technical requirements.
To configure SPS to use Okta multi-factor authentication
-
Download the SPS Okta plugin
SPS customers can download the official plugin from GitHub.
-
Upload the plugin to SPS
Upload the plugin to SPS. For details, see "Using a custom Authentication and Authorization plugin to authenticate on the target hosts" in the Administration Guide.
-
Configure the plugin on SPS
The plugin includes a default configuration file, which is an ini-style configuration file with sections and name=value pairs. You can edit it on the Policies > AA Plugin Configurations page of the SPS web interface.
-
Copy your Okta API token and the name of your Okta site in the [OKTA] section of the configuration file, for example:
[OKTA] APIKey=YOUR-OKTA-API-KEY SiteName=yoursite.okta.com
-
Configure the usermapping settings if needed. SPS must find out which Okta user belongs to the username of the authenticated connection. For that, it can query your LDAP/Microsoft Active Directory server. For details, see Mapping SPS usernames to Okta identities.
-
Configure other parameters of your plugin as needed for your environment. For details, see SPS Okta plugin parameter reference.
-
-
Configure a Connection policy and test it
Configure a Connection policy on SPS. In the AA plugin field of the Connection policy, select the SPS Okta plugin you configured in the previous step, then start a session to test it. For details on how a user can perform multi-factor authentication, see Perform multi-factor authentication with the SPS Okta plugin in terminal connections and Perform multi-factor authentication with the SPS Okta plugin in Remote Desktop connections.
Caution: According to the current Okta policies, your API token expires if it is not used for 30 days. Make sure that you use it regularly, because SPS will reject your sessions if the API token is expired.
SPS Okta plugin parameter reference
This section describes the available options of the SPS Okta plugin.
The plugin uses an ini-style configuration file with sections and name=value pairs. This format consists of sections, led by a [section] header and followed by name=value entries. Note that the leading whitespace is removed from values. The values can contain format strings, which refer to other values in the same section. For example, the following section would resolve the %(dir)s value to the value of the dir entry (/var in this case).
[section name] dirname=%(dir)s/mydirectory dir=/var
All reference expansions are done on demand. Lines beginning with # or ; are ignored and may be used to provide comments.
You can edit the configuration file from the SPS web interface. The following code snippet is a sample configuration file.
[okta] api_key=$ application_id=PSMOktaAAPlugin/%(VERSION)s api_url=https://example.okta.com/api/v1/ default_prefix=o timeout=60 http_socket_timeout=10 rest_poll_interval=1 ignore_conn_err=no [auth] prompt=Press Enter for push notification or type one-time password: disable_echo=yes [connection_limit by=client_ip_gateway_user] limit=0 [authentication_cache] soft_timeout=15 hard_timeout=90 conn_limit=5 ######[WHITELIST]###### [whitelist source=user_list] name=<name-of-user-list-policy> [whitelist source=ldap_server_group] allow=no_user except=<group-1>,<group-2> ######[USERMAPPING]###### [usermapping source=explicit] <user-name-1>=<id-1> <user-name-2>=<id-2> [usermapping source=ldap_server] user_attribute=description [username_transform] append_domain=<domain-without-@-character> [ldap_server] name=<name-of-LDAP-server-policy> [credential_store] name=<name-of-credential-store-policy-that-hosts-sensitive-data> [logging] log_level=info [https_proxy] server=<proxy-server-name-or-ip> port=3128 [question_1] key=<name-of-name-value-pair> prompt=<the-question-itself-in-text> disable_echo=No [question_2]...