# Connecting SailPoint and Okta 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. Select **Virtual Appliance**. A virtual appliance is a Linux-based virtual machine that connects to your sources and apps using SailPoint APIs, connectors, and integrations. For more information about configuring and deploying virtual appliances, refer to [SailPoint Virtual Appliances](). 4. (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](). 5. Configure the authentication to allow SailPoint to connect to the source. For more information, refer to the **Connection Settings** section. 6. 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. Under **Connection Type**, select **Direct Connection** or **Flat File**. - **Direct Connection** - A direct connection fetches data from the **Virtual Appliance Cluster** you choose as the application connector for the source. A direct connection configuration allows for real-time updates. For more information about configuring and deploying virtual appliances, refer to the [Virtual Appliance Reference Guide](). - **Flat File** - Select the flat file if no connector is available, or if another system restricts the connection. This option allows only reading and aggregating data as a generic/delimited application. Provisioning activity is unsupported, and additional configuration pages like connection settings and aggregation settings are unavailable. 5. If you selected **Direct Connection**, in **Virtual Appliance Cluster**, select the virtual appliance cluster that will be used as the application connector for the source. 6. (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](). 7. 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](). 8. 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. In the **Virtual Appliance Cluster** dropdown list, select the virtual appliance to use when communicating with your organization's systems. For more information, refer to [SailPoint Virtual Appliances](). 4. (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](). 5. Configure the authentication to allow SailPoint to connect to the source. Refer to [Connection Settings](<#connection-settings>) for more information. 6. (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](). 7. (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. 8. 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. ### 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. **Client Credentials** is selected for **Grant Type**. Currently, this is the only grant type supported by this source. 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 | For more information on Scopes, refer to [Administrator Permissions](). 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 **Audience** for authorization. 7. Enter the JWT **Issuer** for authorization. This value must be the same as the `client_id`. 8. Enter the JWT **Subject** for authorization. This value must be the same as the `client_id`. 9. 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 into the source configuration. 10. 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. 11. Select **Save**. ### OAuth 2.0 for Pre-existing Sources For existing Okta sources, the Authentication Type is displayed as an **API Token**. While changing the Authentication Type to OAuth 2.0 for the existing source: 1. Add the `private_key`, `private_key_password`, and `accessToken` attributes to the encrypted tag with the connector-encrypted key, using the REST API. For more information, refer to [REST API - Update Source (Partial)](). 2. Remove the `type_name` and `type_displayName` attributes from account schema if they are present. > [!NOTE] > > Aggregation of the `type_name` and `type_displayName` is not supported in Okta managed system for OAuth 2.0 authentication type. It is recommended to use API token authentication for aggregating these attributes. ## 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 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 Enable **Delta Aggregation** for account aggregation. For more information, refer to [Configuring Delta Aggregations for Supported Sources](). Log data older than 90 days is not returned in accordance with Okta's Data Retention Policy. This means that any data changes done prior to 90 days since the last successful account aggregation isn't be captured and a full account aggregation will be required. The Okta source uses the Log API instead of the Event API for delta aggregation. There is a replacement of the Event API entry with the Log API in the source XML file. ### Page Size Settings 1. Set the **User Page Size**. This is the maximum size of each dataset when querying large number of objects. The minimum value is 1 and maximum value is 200. Default: 200. 2. Enter the **Group Page Size** value. This is the maximum size of each dataset while querying a large number of Groups. The default value is 10000, you set and change as per your requirement. 3. Enter the **Logs Page Size** value. This is the maximum size of each dataset while querying large number of Logs. The default value is 1000, you set and change as per your requirement. > [!NOTE] > > The group filter will apply for both account and entitlement aggregation. ### Additional Settings > [!NOTE] > > **Screenshot** > > [![Additional Settings]()]() 1. Enter an **API Rate Limit** for the maximum API rate limit threshold as the maximum permissible call number. For pre-existing sources, 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. Enter an **Aggregation Time Out** value. This is the duration of time in seconds after which an aggregation operation times out. By default, it is 900 seconds. 3. 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 **Disable Group Caching** field. 4. 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. 5. 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. If the VA is configured for multiple CPU cores, it can be configured for a higher number of partition threads to improve performance even further. 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**. ## 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.