One Identity Safeguard for Privileged Sessions 6.0 LTS - DEPRECATED Okta Multi-Factor Authentication - Tutorial

How SPS and Okta work together in detail

Figure 3: How SPS and Okta work together

1. A user attempts to log in to a protected server.

2. Gateway authentication on SPS

   SPS receives the connection request and authenticates the user. SPS can authenticate the user to a number of external user directories, for example, LDAP, Microsoft Active Directory, or RADIUS. This authentication is the first factor.

3. Check if the user is exempt from multi-factor authentication

   You can configure SPS using whitelists and blacklists to selectively require multi-factor authentication for your users, for example, to create break-glass access for specific users.

   • If multi-factor authentication is not required, the user can start working, while SPS records the user's activities. The procedure ends here.

   • If multi-factor authentication is required, SPS continues the procedure with the next step.

   For details on creating exemption lists, see whitelist.

4. Determining the Okta username

   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. The mapping can be as simple as appending a domain name to the gateway username, or you can query an LDAP or Microsoft Active Directory server. For details, see Mapping SPS usernames to Okta identities.

5. Outband authentication on Okta

   If gateway authentication is successful, SPS connects the Okta server to check which authentication factors are available for the user. Then SPS requests the second authentication factor from the user.

   • For OTP-like authentication factors, SPS requests the OTP from the user, and sends it to the Okta server for verification.

   • For the Okta push notification factor, SPS asks the Okta server to check if the user successfully authenticated on the Okta server.

6. If multi-factor authentication is successful, the user can start working, while SPS records the user's activities. (Optionally, SPS can retrieve credentials from a local or external credential store or password vault, and perform authentication on the server with credentials that are not known to the user.)

7. If the user opens a new session within a short period, they can do so without having to perform multi-factor authentication again. After this configurable grace period expires, the user must perform multi-factor authentication to open the next session. For details, see [cache].

Mapping SPS usernames to Okta identities

By default, SPS assumes that the Okta username of the user is the same as the gateway username (that is, the username the user used to authenticate on SPS during the gateway authentication). To identify the users, SPS uses the username (login) field in Okta, which is an email address.

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. You can use the following methods:

• 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.

• 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.

• If you have configured neither the Domain parameter nor the [ldap] section, SPS assumes that the Okta username of the user is the same as the gateway username.

Bypassing Okta authentication

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 [cache].

• You can configure SPS using whitelists and blacklists to selectively require multi-factor authentication for your users, for example, to create break-glass access for specific users. For details on creating exemption lists, see whitelist.

Configure your Okta account for SPS

1. 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.

2. 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.

3. Create an API token.

   Navigate to Admin > API > Tokens, click Create Token, and save it.