# Connecting SailPoint and Okta SaaS To connect SailPoint with Okta, perform the following tasks: ## Adding the Source in SailPoint To connect to SailPoint, perform the following steps. Once the connection is made, you can configure it to meet your company's needs. > [!IMPORTANT] > > By default, the provisioning feature is **disabled**, and the connector only supports read-only operations. To support provisioning operations, you must manually enable the feature in the source configuration. **To configure a new source:** 1. Sign in to SailPoint. 2. Go to **Admin \> Connections \> Sources**. 3. Select **Create New**. 4. Search for the connector by entering the name in the search box, and then select **Actions**. 5. In the **Actions** dropdown list, select the setup method: - [**Express Setup**](<#configuring-a-source-using-express-setup>) - Quickly create a read-only connection to your target system by providing minimal configurations and authentication. On completion, aggregation is automatically started. > **Note** > > Express Setup supports Credential Providers. For information on supported credential providers and configuration, refer to [Credential Providers](). For more information, contact your SailPoint Customer Service Manager. - [**Standard Setup**](<#configuring-a-source-using-standard-setup>) - Provide detailed basic configuration to create the source. Once the source is created, continue with source setup. ### Configuring a Source Using Express Setup Express Setup minimizes the initial configuration process so you can quickly connect the application and immediately begin aggregating user account and entitlement data. 1. Review the directions and select **Start Express Setup**. 2. Review the pre-populated **Source Name**, **Source Owner**, and **Description**. To update, select **Edit**. > **Note** > > The source name must be unique. You can change these settings later in the source configuration. 3. (Optional) If enabled for your organization, select the **Use a Credential Provider** checkbox to manage the source's authentication using a credential provider. > **Note** > > To add a Credential Provider in SailPoint, go to **Admin \> Connections \> Credential Providers**. For more information about credential providers, refer to [Credential Providers](). 4. Configure the authentication to allow SailPoint to connect to the source. For more information, refer to the **Connection Settings** section. 5. Select **Finish**. After a successful test connection, the system creates your source and prompts you to run an aggregation. - If you want to aggregate now, select **Aggregate**. - To see the latest account aggregation history, go to **Account Management \> Account Aggregation**. - To see the list of aggregated source accounts, go to **Account Management \> Accounts**. - If you want to aggregate later, select **Exit**. This returns you to the **Sources** page. Your new source is listed, but contains no accounts or aggregation history yet. ### Configuring a Source Using Standard Setup Use Standard Setup to configure the connector for full feature support. 1. In the **Source Name** field, enter a unique and descriptive name for your source. Source names cannot exceed 128 characters. 2. In the **Description** field, provide additional details about the source to help distinguish it from similar sources. This field allows a maximum of 2,000 characters. 3. In the **Source Owner** field, begin typing the name of an owner. Matches appear after you type two or more letters. For more information, refer to [Assigning a Source Owner](). 4. (Optional) Select a governance group to grant its members [source]() or [role]() sub-admin level oversight of the source and its access. For more information, refer to [Creating and Managing Governance Groups](). 5. If this source represents a primary system containing your organization's personnel records, select the **Authoritative Source** checkbox. For more information, refer to [Creating Identity Profiles](). 6. Select **Continue**. The source is created, and you are navigated to the **Source Setup \> Base Configuration** page. Continue to configure your connected source there. ## Base Configuration Provide the base configuration parameters. Information you entered in the Create New Source dialog is automatically entered into the fields in the Base Configuration page. You can edit this information if necessary. 1. Enter a unique name and description for the source. 2. In the **Source Owner** dropdown list, select the identity that owns this source. - To find a source owner, begin entering their name. 3. (Optional) If enabled for your organization, select the **Use a Credential Provider** checkbox to manage the source's authentication using a credential provider. > **Note** > > To add a credential provider, go to **Admin \> Connections \> Credential Providers**. For more information about credential providers, refer to [Credential Providers](). 4. Configure the authentication to allow SailPoint to connect to the source. Refer to [Connection Settings](<#connection-settings>) for more information. 5. (Optional) In the **Governance Group for Source Management** dropdown list, select a governance group to associate with this source. For more information about governance groups, refer to [Associating Governance Groups with a Source](). 6. (Optional) Choose whether to enable or disable provisioning for the source. Provisioning is disabled by default. - **Enable Provisioning** - Set the toggle to **Enabled** to allow the source to create, update, and deactivate accounts in the connected source system. - **Disable Provisioning** - Set the toggle to **Disabled** to disable provisioning for the source. Disabling provisioning will prevent the creation, updating, or deactivating of accounts on this source. 7. Select **Save**. ## Connection Settings Your source needs to authenticate with the Okta managed system to connect and interact with it. The process to configure authentication changes depending whether you authenticate with an API Token or OAuth 2.0. > [!IMPORTANT] > > CIEM does not support OAuth 2.0 for Okta SaaS connections. Configure the connection using an **API Token**. For more information, refer to [Authenticate with OAuth 2.0](<#authenticate-with-oauth-20>). ### Authenticate with an API Token Configure your source to authenticate with Okta using an API Token. > [!NOTE] > > **Screenshot** > > [![API Token]()]() 1. Enter the **Okta URL** of the host. For example, `https://{yourOktaDomain}.com`. 2. Select the **API Token** radio button. 3. In the **API Token** field, enter the SSWS API token required for Okta authentication. > **Note** > > SSWS specifies the proprietary authentication scheme Okta uses. 4. Select **Save**. ### Authenticate with OAuth 2.0 Configure your source to authenticate with Okta using OAuth 2.0. > [!NOTE] > > For more information on retrieving some of the credentials used in this process, refer to [Implement OAuth for Okta with a Service App](). > [!NOTE] > > **Screenshot** > > [![OAuth 2.0]()]() [![OAuth 2.0]()]() > [!NOTE] > > The Okta managed system does not support aggregation of the `type_name` and `type_displayName` attributes with OAuth 2.0 authentication type. SailPoint recommends that you use **API token** authentication to aggregate these attributes. For more information, refer to [Authenticate with an API Token](<#authenticate-with-an-api-token>). 1. Enter the **Okta URL** of the host. For example, `https://{yourOktaDomain}.com`. 2. Select **Client Credentials** for the **Grant Type**. Currently, this is the only grant type supported. 3. Enter the **OAuth 2.0 Token URL** for token generation. For example: `https://{yourOktaDomain}/oauth2/v1/token` 4. Enter the **Scopes** that must be included while creating JWT token for appropriate operations on the Okta managed system. Scopes must be provided as a space-separated value. For example: | Operation | Scopes | | --- | --- | | Mandatory Scopes | okta.logs.read okta.users.manage okta.groups.manage okta.appGrants.read okta.apiTokens.read | 5. Enter the **JWT Header** that has the algorithm being used for signing the JWT assertion. For example: ```json { "typ": "JWT", "alg": "RS256" } ``` 6. Enter the JWT **Client ID** for authorization. This value must be the same as the `client_id` of the Okta application. 7. Enter the **Private Key** text in Privacy Enhanced Mail (PEM) format to encrypt the JWT assertion. > **Important** > > If your private key was originally provided in the JWK format, you need to convert it to PEM format before entering it. 8. Enter the **Private Key Password** to decrypt the private key that was used for assertion. > **Note** > > The private key password may be referenced as a "KID" or KEY ID in Okta. 9. Select **Save**. ## Change Authentication from API Token to OAuth 2.0 If the Authentication Type is set to **API Token**, you can change the authentication type to OAuth 2.0 by performing the following: 1. Add the `private_key`, `private_key_password`, and `accessToken` attributes to the encrypted tag with the connector-encrypted key, using the REST API. Refer to [REST API - Update Source (Partial)](). 2. Remove the `type_name` and `type_displayName` attributes from account schema if they are present. ## Machine Identity Governance Settings Use these settings to control which Okta applications are aggregated into datasets. **To configure application aggregation:** 1. Go to **Machine Identity Governance Settings**. 2. Select the **Aggregate OpenID Connect Applications Only** checkbox to aggregate only OpenID Connect applications. This checkbox is selected by default. Clear the checkbox to aggregate all application types. 3. Select **Save**. ## Activity Insights Settings SailPoint pulls in activity data in the form of events like user logins, password changes, and content updates within the application. You can view an identity’s activity data within an application to discover trends for that user. > [!IMPORTANT] > > Contact your SailPoint Customer Success Manager (CSM) for more information on Activity Insights. For more information on utilizing activity data, refer to [Activity Insights](). Activity Insights Settings allows you to gather account information and activity data from Okta. To enable Activity Insights for the Okta application, refer to [Prerequisites]() for more information. To configure Activity Insights, complete the following: > [!NOTE] > > **Screenshot** > > [![Activity Insights Settings]()]() 1. Go to **Activity Insights Settings**. 2. Select **Enable Activity Insights** to view access to data insights on source and application activity such as logins and other app-specific events. 3. Select **Save**. ## Aggregation Settings Configure how your source handles aggregation. For more information about aggregation, refer to [Loading Account Data](). > [!NOTE] > > **Screenshot** > > [![Aggregation Settings]()]() [![Aggregation Settings]()]() [![Aggregation Settings]()]() ### Filter Settings > [!NOTE] > > For custom attribute filters to work, you must ensure the option to **Enable List Users With Search** is selected. Set the condition to filter out the accounts and groups in the respective fields. #### Filter Conditions for Accounts For example, if the added filter is `status eq "STAGED"` then only the `staged` accounts are aggregated. Refer to the following table: | Filter | Description | | --- | --- | | `status eq "STAGED"` | Users that have a status of STAGED | | `status eq "PROVISIONED"` | Users that have a status of PROVISIONED | | `status eq "ACTIVE"` | Users that have a status of ACTIVE | | `status eq "RECOVERY"` | Users that have a status of RECOVERY | | `status eq "PASSWORD_EXPIRED"` | Users that have a status of PASSWORD\_EXPIRED | | `status eq "LOCKED_OUT"` | Users that have a status of LOCKED\_OUT | | `status eq "DEPROVISIONED"` | Users that have a status of DEPROVISIONED | | `lastUpdated lt "yyyy-MM-dd'T'HH:mm:ss.SSSZ"` | Users last updated before a specific timestamp | | `lastUpdated eq "yyyy-MM-dd'T'HH:mm:ss.SSSZ"` | Users last updated at a specific timestamp | | `lastUpdated gt "yyyy-MM-dd'T'HH:mm:ss.SSSZ"` | Users last updated after a specific timestamp | | `id eq "00u1ero7vZFVEIYLWPBN"` | Users with a specified ID | | `profile.login eq "login@example.com"` | Users with a specified login | | `profile.email eq "email@example.com"` | Users with a specified email address | | `profile.firstName eq "John"` | Users with a specified firstName | | `profile.lastName eq "Smith"` | Users with a specified lastName | | `profile.Custom_Integer_Array eq "23"` | Users with a specified array attribute | | `profile.Custom_String eq "Custom Value for String__Updated"` | Users with a specified custom attribute | #### Filter Conditions for Groups This setting is optional however it is available by default. The filter brings a subset of groups during aggregation, for example `type eq "OKTA_GROUP"`. The default filter (`type eq "BUILT_IN" or type eq "OKTA_GROUP"`) only aggregates Okta and built-in groups. | Filter | Description | | --- | --- | | `type eq "OKTA_GROUP"` | Groups that have a type of OKTA\_GROUP | | `type eq "APP_GROUP"` | Groups that have a type of APP\_GROUP | | `type eq "BUILT_IN"` | Groups that have a type of BUILT\_IN | | `lastUpdated lt "yyyy-MM-dd'T'HH:mm:ss.SSSZ"` | Groups with profile last updated before a specific timestamp | | `lastUpdated eq "yyyy-MM-dd'T'HH:mm:ss.SSSZ"` | Groups with profile last updated at a specific timestamp | | `lastUpdated gt "yyyy-MM-dd'T'HH:mm:ss.SSSZ"` | Groups with profile last updated after a specific timestamp | | `lastMembershipUpdated lt "yyyy-MM-dd'T'HH:mm:ss.SSSZ"` | Groups with memberships last updated before a specific timestamp | | `lastMembershipUpdated eq "yyyy-MM-dd'T'HH:mm:ss.SSSZ"` | Groups with memberships last updated at a specific timestamp | | `lastMembershipUpdated gt "yyyy-MM-dd'T'HH:mm:ss.SSSZ"` | Groups with memberships last updated after a specific timestamp | | `id eq "00g1emaKYZTWRYYRRTSK"` | Group with a specified ID | For the full list of supported filters, including Application filters and filter combination examples, refer to [Supported Aggregation Filters](). ### Delta Aggregation > [!NOTE] > > The Okta SaaS connector supports delta aggregation for accounts only. Enable **Delta Aggregation** to aggregate new accounts or the accounts that have been changed since the last aggregation. > [!NOTE] > > For new sources delta aggregation is enabled by default. Refer to [Configuring Delta Aggregations for Supported Sources]() for more details on how to configure delta aggregations on a supported source. Refer to [Delta Aggregation]() to understand more about the behavior of delta aggregation in Okta SaaS. ### Page Size Settings 1. Enter the **User Page Size**. This is the maximum size of each dataset when querying large number of objects. Default: 200. Minimum value: 1. Maximum value: 200. 2. Enter the **Group Page Size** value. This is the maximum size of each dataset while querying a large number of Groups. Default: 10000. Minimum value: 1. Maximum value: 10000. 3. Enter the **Logs Page Size** value. This is the maximum size of each dataset while querying large number of Logs. Default: 1000. Minimum value: 1. Maximum value: 1000. 4. Select **Save**. ### Additional Settings > [!NOTE] > > **Screenshot** > > [![Additional Settings]()]() 1. Enter the **API Rate Limit** for the maximum API rate limit threshold as the maximum permissible call number. If you have the `maxPermissibleCalls` attribute, you can change its value. This value is expressed as a percentage without the percent symbol (%). By default, it is `90`. 2. Select **Disable Group Caching** to disable the cache creation of user groups. The connector fetches user profiles followed by groups during account aggregation. The Okta source creates a group cache to improve aggregation performance, as exemplified in the following steps: 1. The source creates a cache of users connected to groups. 2. The source then fetches the user profiles. 3. The source maps the groups of the fetched user profiles to the cache created originally. This cache creation works best in environments where there are fewer connections between users and groups. Because of API limitations, the cache creation can take a longer time the more connections there are. To skip the cache creation and fetch the user profiles followed by groups, enable the option to **Disable Group Caching**. 3. Select **Enable Group Skinny User** to enable the `skinny_user` endpoint to fetch the groups connected to a user in the Okta source. This attribute is applicable only for caching the approach of account aggregation. 4. Select **Enable List Users With Search** to run account aggregation with Okta's **List Users with Search** feature. By default, the Okta source supports the managed system's **List Users with Filter** feature for account aggregation. The **List Users with Search** feature searches for users based on the properties specified in the search parameter (case insensitive). This operation supports pagination to a maximum of 50000 results. #### Partitioning Settings > [!NOTE] > > **Screenshot** > > [![Partitioning Settings]()]() Select the option to **Enable Partitioning** to process the data in parallel across multiple threads. 1. Enter a **Number of Partitioning Threads** value. By default, it is 2. 2. Select **Save**. ## Provisioning Settings Use this setting to configure how the connector updates accounts when you disable them in SailPoint. Account changes are provisioned to the source using the selected method. > [!NOTE] > > **Screenshot** > > [![Provisioning Settings]()]() To configure provisioning settings, complete the following: 1. Under **Disable Operation Setting**, select one of the following: - Select **Suspend** to temporarily disable the account. - Select **Deprovision** to remove all applications from the account and deactivate it. Enable **Send Email** to send a deactivation email to the Okta's administrator email address. 2. Select **Save**. ## SailPoint CIEM Settings SailPoint's Cloud Infrastructure Entitlement Management (CIEM) enhances identity governance by providing a deeper view into the effective access of entitlements to resources and your users' entitlement activity in your cloud infrastructure. > [!IMPORTANT] > > You must have a SailPoint Cloud Infrastructure Entitlement Management (CIEM) license to enable cloud governance features. Contact your SailPoint Customer Success Manager to request access. For more information on CIEM Cloud Governance, refer to [CIEM Cloud Governance Overview](). CIEM settings allows you to collect cloud resource data and display the total access an identity has to your cloud systems. ### Prerequisites - Before enabling CIEM and adding your Application IDs, you need to configure Okta to work with CIEM. For more information on these steps, refer to [Configuring Okta for SailPoint CIEM](). - To enable SailPoint CIEM for the Okta SaaS connector, you must configure API Token authentication. CIEM does not support OAuth 2.0 authentication, and using it will cause test connection errors. To configure CIEM, complete the following: > [!NOTE] > > **Screenshot** > > [![CIEM Settings]()]() 1. Go to **CIEM Settings**. 2. Select **Enable Cloud Infrastructure Entitlement Management (CIEM)** to view access to cloud resources and infrastructure granted through entitlements. 3. Enter the **Application ID** for the configured Okta instance. Separate multiple entries with a comma. 4. Select **Save**. ## Review and Test Perform a test to confirm the connection to SailPoint. 1. Go to **Review and Test**. 2. Confirm that the entries in each field are correct. If you note any mistakes, return to the section and make corrections. 3. Select **Test Connection**. ## SailPoint Application Onboarding SailPoint application onboarding enables you to easily onboard new applications and create sources following the successful onboarding of a discovery source. To use this feature, continue to **Discovered Applications** in the SailPoint user interface. For more information, refer to [Application Onboarding]() in the SailPoint SaaS documentation.