# Supported Features The Okta connector supports the following features: > [!NOTE] > > Before you can use any item marked with an asterisk (\*), SailPoint must activate the feature for your site. For more information on opening a support ticket, refer to [Working With Services](). - Load accounts - \*Provision accounts - Unlock accounts - \*Access Certifications (certification of entitlements connected to accounts) - Delta Aggregation - \*Password management - Enable and disable accounts - Delete accounts - Pass-through authentication For more information on features, refer to [Source Features](). ## The `factors` Attribute The Okta source supports the multi-valued `factors` attribute related to the `Multi-Factors` attribute in the Okta managed system. The Okta source can aggregate and provision the `factors` attribute. Provisioning this attribute maps to the Enroll Multi-Factors operation in the Okta managed system. > [!NOTE] > > To aggregate the Multi-Factors data associated with an aggregated user, you must add the `factors` attribute to the account schema of the source and execute full aggregation one time. For more information on adding account schema attributes, refer to [Adding Attributes to a Source Schema](). `factors` data is aggregated as shown in the following example: - Attribute Name - `factors` - Attribute Value - `factorType=sms ; provider=OKTA , factorType=push ; provider=OKTA, factorType=token:software:totp ; provider=OKTA` > [!NOTE] > > Adding the `factors` attribute will increase the aggregation execution time. ## Multiple Group Objects The Okta source supports the multiple group objects. Following are the details of features: | Features | Users | | --- | --- | | Create | ✔ | | Aggregate | ✔ | | Password Management | ✔ | | Group Entitlements (Read, Request, Revoke) | ✔ Groups, Role, Applications - (You need to add the schema object type explicitly) | ## Group Entitlements Group Entitlements are entitlement types for which SailPoint provides ability to aggregate additional details of these entitlement types from the managed system. These objects have separate schema defining list of attributes that aggregation task fetches as additional details when aggregation is run for that Group Entitlement type. | Features | Users | Applications | | --- | --- | --- | | Aggregation | ✔ | ✔ | ## Using Multiple Group Entitlements `groupTargetsHelpDeskAdmin` (aggregates the Group Target for HELP\_DESK\_ADMIN role) By default, for the Okta source supports the `groupTargetsHelpDeskAdmin` attribute is not a part of account schema. To add this attribute to the existing schema, refer to [Adding Attributes to a Source Schema](). The applications attribute is a multi-valued entitlement attribute, and it aggregates the Group Target for HELP\_DESK\_ADMIN role assigned to a user. Use [createSchema API]() to create new group schema for your source. Here is an example for API body content for adding entitlements to the source. ```json { "name": "groupTargetHelpDeskAdmin", "nativeObjectType": "groupTargetHelpDeskAdmin", "identityAttribute": "groupId", "displayAttribute": "name", "hierarchyAttribute": null, "includePermissions": false, "features": [], "configuration": {}, "attributes": [ { "name": "groupId", "type": "STRING", "schema": null, "description": "Unique key for group", "isMulti": false, "isEntitlement": false, "isGroup": false }, { "name": "name", "type": "STRING", "schema": null, "description": "Name of the group", "isMulti": false, "isEntitlement": false, "isGroup": false }, { "name": "created", "type": "STRING", "schema": null, "description": "Timestamp when group was created", "isMulti": false, "isEntitlement": false, "isGroup": false }, { "name": "description", "type": "STRING", "schema": null, "description": "Description of the group", "isMulti": false, "isEntitlement": false, "isGroup": false }, { "name": "lastMembershipUpdated", "type": "STRING", "schema": null, "description": "Timestamp when group's memberships were last updated", "isMulti": false, "isEntitlement": false, "isGroup": false }, { "name": "type", "type": "STRING", "schema": null, "description": "Determines how a group's profile and memberships are managed", "isMulti": false, "isEntitlement": false, "isGroup": false }, { "name": "lastUpdated", "type": "STRING", "schema": null, "description": "Timestamp when group's profile was last updated", "isMulti": false, "isEntitlement": false, "isGroup": false }, { "name": "objectClass", "type": "STRING", "schema": null, "description": "Determines the group's profile", "isMulti": true, "isEntitlement": false, "isGroup": false } ] } ``` ## Additional Configurations ### Applications If the `applications` schema is configured, use the following parameters to fine tune the application's aggregation. - **Filter Conditions for Applications** - This is an optional condition to bring a subset of Applications during aggregation. For example, `status eq "ACTIVE"`. Refer to the [Update Source (Partial)]() for more information. ```http PATCH https://{orgName}.api.identitynow.com/v3/sources/{OktaSourceID} [ { "op": "add", "path": "/connectorAttributes/applicationAggFilter", "value": "status eq \"INACTIVE\"" } ] ``` - **Application Page Size** - Sets the maximum size of each dataset when querying a large number of applications by adding the entry key as follows: ```http PATCH https://{orgName}.api.identitynow.com/v3/sources/{OktaSourceID} [ { "op": "add", "path": "/connectorAttributes/appsPageSize", "value": 200 } ] ``` The default value is `200`. For more information, refer to [Update Source (Partial)](). - **Disable Application Caching** - To skip creation of application cache, set `noAppCaching` to `true`. ```http PATCH https://{orgName}.api.identitynow.com/v3/sources/{OktaSourceID} [ { "op": "add", "path": "/connectorAttributes/noAppCaching", "value": true } ] ``` For more information, refer to [Update Source (Partial)](). - **Enable Application Skinny User** - (Applicable only for caching the approach of account partitioning aggregation) - Enables the `skinny_user` endpoint to bring applications connected to user in Okta connector by adding the entry key as follows: ```http PATCH https://{orgName}.api.identitynow.com/v3/sources/{OktaSourceID} [ { "op": "add", "path": "/connectorAttributes/applicationSkinnyUsers", "value": true } ] ``` For more information, refer to [Update Source (Partial)](). > [!CAUTION] > > Adding the `applications` attribute and the corresponding `application` schema will increase the execution time for the aggregation operation. ### `groupTargetsHelpDeskAdmin` If the `groupTargetsHelpDeskAdmin` schema is configured, use the following parameters to fine tune the application's aggregation. - Filter conditions for `groupTargetsHelpDeskAdmin` - This is an optional condition to bring a subset of `groupTargetsHelpDeskAdmin` during aggregation. For example, `type eq "BUILT_IN"`. For more information, refer to the [Update Source (Partial)](). ```http PATCH https://{orgName}.api.identitynow.com/v3/sources/{OktaSourceID} [ { "op": "add", "path": "/connectorAttributes/groupTargetAggFilter", "value": "type eq \"BUILT_IN\" OR \"OKTA_GROUP\" " } ] ``` ## Support for APP Target and APP Instance Target for APP\_ADMIN Role ### APP Target Aggregation > [!CAUTION] > > Enabling this feature will have a performance impact. By default, for the Okta source the `applicationsManagedByRole` attribute is not a part of the account schema. To add this attribute to the existing schema, refer to [Adding Attributes to a Source Schema](). The `applicationsManagedByRole` attribute is a multi-valued entitlement attribute, and it aggregates the APP Target and APP Target Instance for `APP_ADMIN` assigned to a user separated by the delimiter, `###`. ### APP Target Provisioning Supports add/remove of `applicationsManagedByRole` attribute. > [!NOTE] > > If `APP_ADMIN` role is not already assigned to the user then while assigning the APP Target and APP Instance Target, the APP\_ADMIN role is assigned to user automatically. ## Support for Group Target for HELP\_DESK\_ADMIN Role ### Group Target Aggregation > [!CAUTION] > > Enabling this feature will have a performance impact. By default, for the Okta source the `groupTargetsHelpDeskAdminRole` attribute is not a part of the account schema. To add this attribute to the existing schema, refer to [Adding Attributes to a Source Schema](). The `groupTargetsHelpDeskAdminRole` attribute is a multi-valued entitlement attribute, and it aggregates the Group Target for the `HELP_DESK_ADMIN` role assigned to a user. > [!NOTE] > > If you select string for the attribute type, then only the `groupId` of the Group Target for the `HELP_DESK_ADMIN` role assigned to a user is populated. ### Group Target Provisioning You can add or remove `groupTargetsHelpDeskAdminRole` attribute via provisioning. > [!NOTE] > > If the `HELP_DESK_ADMIN` role is not already assigned to a user, then it is automatically assigned while assigning the `groupTargetsHelpDeskAdminRole`. ## Support for Aggregation of Custom Roles The Okta source supports aggregation of custom roles directly associated with both accounts and groups in the following format: `RoleName#ResourceSetName` In order to leverage this functionality, you need to add these attributes into the account and group schemas: - **Attribute Name** - `customRoles` - **Property Type** - string - Select the **Entitlement**, **Multivalued** checkboxes. The Okta source also supports the addition and removal of Custom Roles from the user. ## Support for Custom Attributes The Okta connector supports the aggregation and provisioning of custom attributes belonging to User Profile. In order to leverage this functionality, user needs to add these attributes into the account: - **Attribute Name** - `customAttribute` - **Type** - string > [!NOTE] > > Custom attributes can have multiple values. Custom Attribute is also supported for account aggregation. ## Support for the Standard Roles Associated with Group The Okta source supports the aggregation of Standard roles associated with Groups. In order to leverage this functionality, you need to add these attributes into the group schema: - **Attribute Name** - `roles` - **Property Type** - string - Select the **Entitlement**, **Multivalued** checkboxes. ## Enabling and Disabling Accounts Enabling a User Account also activates a user in Okta. Disabling a User Account will either suspend or deprovision a user in Okta depending on your provisioning configuration. For more information on configuration, refer to [Provisioning Settings](). Account Update is supported for the suspended/deprovisioned account while performing the Enable operation. ## Privilege Classification SailPoint Privilege Classification helps organizations systematically categorize and manage the privilege levels of entitlements within their sources. By classifying entitlements as high, medium, or low, administrators can better understand the potential risk and impact associated with specific access rights. This allows automatic assignment of privilege levels based on system recommendations, custom-defined criteria, or a same level across all entitlements. | Privilege Level | Description | | --- | --- | | High | Administrative level access to accounts | | Medium | Administrative level access for a specific role or function | | Low | Only basic access of data | > [!NOTE] > > To manage Privilege Classification, users must have administrative roles such as Org Admin, Source Admin or Source Sub-Admin. For more information, refer to [Managing Privilege Classification](). ## Password Management If Password Management is enabled for your organization, you can change the password for a user of the source. After enabling password management on the source, be aware of the following: - The password policy defined in SailPoint applies to accounts on this source. - If you change the password for an application connected to this source, the change will automatically be made to the source itself. For more information on configuring password management, refer to [Password Management Overview]().