# SailPoint SCIM 2.0 SaaS Connector Documentation > SCIM 2.0 SaaS Connector Documentation # Documentation # Connecting SailPoint and SCIM 2.0 SaaS To connect SailPoint with SCIM 2.0, 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 **Configure**. 5. In the **Source Name** field, enter a unique and descriptive name for your source. Source names cannot exceed 128 characters. 6. 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. 7. 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](). 8. (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](). 9. 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](). 10. 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 The following information is required for SailPoint to connect and interact with a SCIM 2.0 compliant managed system. > [!NOTE] > > **Screenshot** > > [![alt text]()]() 1. Select **Connection Settings** from the menu. 2. Enter the **Base URL** of the SCIM 2.0 compliant managed system. 3. From the **Authentication Type** dropdown, select one of the following: - [Basic Authentication](<#basic-authentication>) - [API Token](<#api-token>) - [OAuth 2.0](<#oauth-20>) - [Custom Authentication](<#custom-authentication>) ### Basic Authentication > [!NOTE] > > **Screenshot** > > [![alt text]()]() 1. Enter the **Username** for basic authentication. 2. Enter the corresponding **Password**. 3. Select **Save**. ### API Token You can use an **API Token** for authentication on the SCIM 2.0 source. Only bearer tokens are supported, and they either come with a long validity period or do not expire. > [!NOTE] > > **Screenshot** > > [![alt text]()]() 1. Enter the **API Token**. > **Note** > > By default, the API Token authentication supports the bearer token type. If you want to change the token type you can add the `tokenType` key and the value that is supported by your SCIM Server. Use the Update Source Partial REST API to update the token type. For more information, refer to [REST API - Update Source (Partial)](). 2. Select **Save**. ### OAuth 2.0 OAuth 2.0 authentication uses an access token for a connection. An access token is generated based on the selected grant type, which then allows the generated token to be used. 1. From the **Grant Type** dropdown, select one of the following: - [Password](<#password>) - [Refresh Token](<#refresh-token>) - [Client Credentials](<#client-credentials>) - [JWT Grant](<#jwt-grant>) #### Password > [!NOTE] > > **Screenshot** > > [![alt text]()]() [![alt text]()]() 1. In the **OAuth 2.0 Token URL** field, enter the OAuth 2.0 Token URL for generating the access token. 2. Enter the **Client ID** and accompanying **Client Secret** created in the SCIM 2.0 source. 3. Enter the **Username** and **Password** the connector needs to authenticate with the SCIM 2.0 source. 4. For **OAuth Headers** add the **Key** and **Value** pairs to set up the custom headers for the access token. The SCIM 2.0 SaaS source adheres to the generalized specifications of the OAuth 2.0 grant types. For some managed target systems, however, custom headers may be required to be part of the access token generation request. You can add the custom headers as an attribute. Use the **Add Another** and **Trash Bin** buttons to add or remove fields. 5. Enter the **OAuth Headers to Exclude**. By default, an Authorization BASIC header with Base64-encoded client ID and client secret are a part of the access token generation request. Some managed target systems do not support this header. If there is no Authorization BASIC header required for such managed target systems, it can be excluded from the request. 6. Set the custom **OAuth Request Parameters** for the access token. For some managed target systems, custom request parameters may be required to be part of the access token generation request. You can add the custom request parameter as an attribute. For example, some managed target systems require explicit `scope` attributes in request parameters. In that case, add the `scope` as the key and value in OAuth Request Parameters. Use the **Add Another** and **Trash Bin** buttons to add or remove fields. 7. Enter the **OAuth Body Attributes to Exclude**. To remove any of the standard request parameters that are not supported by managed systems access token generation requests, you must configure the request parameters to exclude them from the access token request. 8. Select **Save**. #### Refresh Token > [!NOTE] > > **Screenshot** > > [![alt text]()]() [![alt text]()]() 1. Enter the **OAuth 2.0 Token URL** for generating the access token. 2. Enter the **Client ID** and accompanying **Client Secret** created in the SCIM 2.0 source. 3. Enter the **Refresh Token** used to generate an access token. 4. For **OAuth Headers** add the **Key** and **Value** pairs to set up the custom headers as part of the access token. The SCIM 2.0 SaaS source adheres to the generalized specifications of the OAuth 2.0 grant types. For some managed target systems, however, custom headers may be required to be part of the access token generation request. You can add the custom headers as an attribute. Use the **Add Another** and **Trash Bin** buttons to add or remove fields. 5. Enter the **OAuth Headers to Exclude**. By default, an Authorization BASIC header with Base64-encoded client ID and client secret are a part of the access token generation request. Some managed target systems do not support this header. If there is no Authorization BASIC header required for such managed target systems, it can be excluded from the request. 6. Set the custom **OAuth Request Parameters** for the access token. For some managed target systems, custom request parameters may be required to be part of the access token generation request. You can add the custom request parameter as an attribute. For example, some managed target systems require explicit `scope` attributes in request parameters. In that case, add the `scope` as the key and value in OAuth Request Parameters. Use the **Add Another** and **Trash Bin** buttons to add or remove fields. 7. Enter the **OAuth Body Attributes to Exclude**. To remove any of the standard request parameters that are not supported by managed systems access token generation requests, you must configure the request parameters to exclude them from the access token request. 8. Select **Save**. #### Client Credentials > [!NOTE] > > **Screenshot** > > [![alt text]()]() [![alt text]()]() 1. Enter the **OAuth 2.0 Token URL** for generating the access token. 2. Enter the **Client ID** and accompanying **Client Secret** created in the SCIM 2.0 source. 3. For **OAuth Headers** add the **Key** and **Value** pairs to set up the custom headers as part of the access token. The SCIM 2.0 SaaS source adheres to the generalized specifications of the OAuth 2.0 grant types. For some managed target systems, however, custom headers may be required to be part of the access token generation request. You can add the custom headers as an attribute. Use the **Add Another** and **Trash Bin** buttons to add or remove fields. 4. Enter the **OAuth Headers to Exclude**. By default, an Authorization BASIC header with Base64-encoded client ID and client secret are a part of the access token generation request. Some managed target systems do not support this header. If there is no Authorization BASIC header required for such managed target systems, it can be excluded from the request. 5. Set the custom **OAuth Request Parameters** for the access token. For some managed target systems, custom request parameters may be required to be part of the access token generation request. You can add the custom request parameter as an attribute. For example, some managed target systems require explicit `scope` attributes in request parameters. In that case, add the `scope` as the key and value in OAuth Request Parameters. Use the **Add Another** and **Trash Bin** buttons to add or remove fields. 6. Enter the **OAuth Body Attributes to Exclude**. To remove any of the standard request parameters that are not supported by managed systems access token generation requests, you must configure the request parameters to exclude them from the access token request. 7. Select **Save**. #### JWT Grant > [!NOTE] > > **Screenshot** > > [![alt text]()]() [![alt text]()]() [![alt text]()]() 1. Enter the **OAuth 2.0 Token URL** for generating the access token. 2. Enter the **JWT Header**. You can add additional headers in JSON format if required. The header consists of the type of the token (JWT) and the signing algorithm being used. For example, you can use: ```json { "typ" : "JWT", "alg" : "RS256" } ``` 3. Enter the **Subject**. 4. Enter the **Issuer**. 5. Enter the **Audience** for authorization. This is the recipient for which the JWT is intended. 6. Enter the **Private Key** and the **Private Key Password**. 7. For **OAuth Headers** add the **Key** and **Value** pairs to set up the custom headers as part of the access token. The SCIM 2.0 SaaS source adheres to the generalized specifications of the OAuth 2.0 grant types. For some managed target systems, however, custom headers may be required to be part of the access token generation request. You can add the custom headers as an attribute. Use the **Add Another** and **Trash Bin** buttons to add or remove fields. 8. Enter the **OAuth Headers to Exclude**. By default, an Authorization BASIC header with Base64-encoded client ID and client secret are a part of the access token generation request. Some managed target systems do not support this header. If there is no Authorization BASIC header required for such managed target systems, it can be excluded from the request. 9. Set the custom **OAuth Request Parameters** for the access token. For some managed target systems, custom request parameters may be required to be part of the access token generation request. You can add the custom request parameter as an attribute. For example, some managed target systems require explicit `scope` attributes in request parameters. In that case, add the `scope` as the key and value in OAuth Request Parameters. Use the **Add Another** and **Trash Bin** buttons to add or remove fields. 10. Enter the **OAuth Body Attributes to Exclude**. To remove any of the standard request parameters that are not supported by managed systems access token generation requests, you must configure the request parameters to exclude them from the access token request. 11. Select **Save**. ### Custom Authentication > [!NOTE] > > **Screenshot** > > [![alt text]()]() [![alt text]()]() [![alt text]()]() [![alt text]()]() 1. Enter the **Base URL** to connect to the managed system. For example: ```text https://api.testurl.com ``` 2. Select Custom Authentication as the **Authentication Type**. 3. (Optional) fields display that you can configure as your authentication configuration requires: - Username - Password - API Token - Resource Owner Username - Resource Owner Password - Private Key - Private Key Password - Client ID - Client Secret - Refresh Token 4. Configure **OAuth Headers** and **OAuth Request Parameters** by entering the Key and Value parameters for the token generation. Use **Add Another** and the **Recycle bin** to add and remove fields as needed. > **Example 1** > > ```text > oauth_headers: { > 'Content-Type': 'application/x-www-form-urlencoded' > } > ``` > **Example 2** > > ```text > oauth_request_parameters: { > client_id: '$application.clientId$', > client_secret: '$application.clientSecret$', > grant_type: 'client_credentials', > scope: 'scim' > } > ``` > **Example 3 - Using the **Client Secret** sensitive attributes** > > ```xml > > > > > > > > ``` 5. Enter the **OAuth Headers to Exclude**. By default, an Authorization BASIC header with Base64-encoded client ID and client secret are a part of the access token generation request. Some managed target systems do not support this header. If there is no Authorization BASIC header required for such managed target systems, it can be excluded from the request. 6. Enter the **OAuth Body Attributes to Exclude**. Remove any of the standard request parameters that are not supported by the managed systems access token generation requests to exclude them from the access token request. ## Aggregation Settings Configure settings related to account and group aggregation processes. For more information about aggregation, refer to [Loading Account Data](). ### Configure Aggregation Filters Configure the scope of the records aggregated for accounts and groups. You can also enable and configure explicit attribute requests. > [!NOTE] > > **Screenshot** > > [![alt text]()]() 1. Enter the **Filter Condition For Accounts** to aggregate the SCIM User resources. For example, `userName sw "Admin"` 2. Enter the **Filter Conditions For Groups** to aggregate the SCIM Group resources. For example, `displayName sw "SecGroup"` 3. (*Optional*) Enable **Explicit Attribute Request** to get the required schema attributes in a request. In certain instances the SCIM server, by default, does not return all attributes. To ensure you aggregate all attributes, select this option to add the requested schema attributes into the URL. For example, the `organizationId` attribute is present in the schema but it is not returned by default. If you request it, the URL will be as follows: `{host}/Users?attributes=firstName,organizationId`. If you do not request it, the URL is: `{host}/Users`. 4. Select **Save**. ### Configure Delta Aggregation Settings Enable and configure delta aggregation. > [!NOTE] > > **Screenshot** > > [![alt text]()]() 1. Enable **Delta Aggregation** to speed up the aggregation process and only aggregate accounts that have received updates since the last aggregation process. > **Note** > > Delta Aggregation does not fetch accounts that are deleted on the SCIM system. Delta Aggregation is applicable only for those SCIM 2.0 systems that support the `lastModified` attribute and filter for it. > **How to update existing sources to enable delta support** > > Use the REST APIs for the source that needs to be updated. For example: > > ```bash > curl -L -X PATCH 'https://sailpoint.api.identitynow.com/v3/sources/:id' \ > -H 'Content-Type: application/json-patch+json' \ > -H 'Accept: application/json' \ > -H 'Authorization: Bearer ' \ > --data-raw '[ > { > "op": "add", > "path": "/connectorAttributes/supportsDeltaAgg", > "value": true > }, > { > "op": "add", > "path": "/connectorAttributes/deltaAggregationEnabled", > "value": true > } > ]' > ``` > > > **Note** > > > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. 2. Enter the **Date Format**. It is the date and time format supported by the SCIM server. By default the date format is: `YYYY-MM-DDTHH:mm:ss[Z]` 3. Enter a valid **Server Time Zone** in which the SCIM 2.0 system server is configured. For example, you can use GMT or PST. This time zone is used for performing delta aggregation. If a time zone value is not provided the default value will be UTC. 4. Select **Save**. ### Configure Page Size Settings Configure how many account or group records the connector gets when iterating over large datasets. > [!NOTE] > > **Screenshot** > > [![alt text]()]() 1. Enter the **Account Page Size** as the number of records that you can get in one request. 2. Enter the **Group Page Size** as the number of records that you can get in one request. 3. Select **Save**. ### Configure Partitioning Settings Configure partitioning aggregation to enable parallel data processing across multiple threads, enhancing the performance of aggregation tasks. The connector uses a User Partitioning Scheme made up of partitioning values to determine how it partitions accounts during aggregation processes. For more information, refer to [Filtering]() in the *System for Cross-domain Identity Management: Protocol* document. > [!NOTE] > > The linked document is not maintained by SailPoint and is subject to change without notice. > [!NOTE] > > **Screenshot** > > [![alt text]()]() To configure partitioning: 1. Select **Enable Partitioning** to enable the feature. The **User Partitions** field displays. 2. In the **User Partitions** field, enter a filter which makes up the User Partitioning Scheme. Press Enter to add it to a growing list. The following are examples of filters you can use for partitioning: - `userName sw "a"` - `userName eq "bjensen"` - `meta.lastModified gt "2025-05-13T04:42:34Z"` - `title pr and userType eq "Employee"` - `userType eq "Employee"` 3. Select **Save**. ## Additional Aggregation Information ### Accounts After you create and test the connection and save the source, you can load accounts. You must first discover the schema and identify attributes to use for required identity data before you load the accounts. > [!IMPORTANT] > > SCIM 2.0 compliant server supports the schema and `ResourceType` endpoint according to the SCIM 2.0 specification. ### Discovering the Schema Discover the schema by performing the following steps: 1. Select **Import Data**. 2. Select **Account Schema** in the menu. 3. Select **Discover**. 4. Identify the attributes to be used for Account Name and Account ID. Mark them in the respective columns. > [!CAUTION] > > If this source is going to be used as an authoritative source for an identity profile, both the Account Name and Account ID must be unique. If not, source accounts could correlate to the first Identity that includes that ID or Name instead of creating an additional Identity. ### Loading Accounts After you have discovered the schema and identified required attributes, you can load accounts by performing the following steps: 1. Select **Import Data**. 2. Select **Start** to start a manual aggregation. 3. Review the results in the **Aggregation Activity** log. ## Additional Settings > [!NOTE] > > **Screenshot** > > [![alt text]()]() [![alt text]()]() [![alt text]()]() 1. Select **Additional Settings** from the menu. 2. You have several options to configure HTTP Request Headers as needed for your organization. Enter the HTTP **Content-Type** header value to use for the SCIM requests. The default value is `application/scim+json`. 3. Enter the HTTP **Accept** header value to use for the SCIM requests. The default value is `application/scim+json`. > **Note** > > The SCIM 2.0 SaaS source does not include the read-only attributes in HTTP PATCH requests. 4. Select the **Use HTTP PATCH** checkbox if the SCIM server supports it for provisioning processes. 5. Select the **Skip Group Update** checkbox if the SCIM server supports modification of group information using the user's endpoint. 6. Enter the key for the **Account Lock Status Attribute**. For example, `accountLocked`. > **Note** > > The **Account Lock Status Attribute** must be from the extension schema. 7. Select **Save**. ## Non-Compliant Settings The SCIM 2.0 SaaS source supports the configuration of a non-compliant SCIM server. > [!NOTE] > > **Screenshot** > > [![alt text]()]() [![alt text]()]() [![alt text]()]() [![alt text]()]() 1. Select **Non-Compliant Settings** from the menu. 2. Enable the **Non-Compliant Server** option to skip SCIM 2.0 validation for each response from this server. Use this if your SCIM 2.0 Server is not fully compliant with SCIM 2.0 specifications. > **Note** > > The SCIM 2.0 SaaS source will not use the schema response; it will use the populated core or extended schema mentioned in the SCIM 2.0 specifications. For more information, refer to [Schema Reference](). 3. Enter the **Schema Attribute** and **JSON Path**. For any new attribute, you must add it in the schema and add its JSON Path to the JSON Path Mapping. Use **Add Another** and the **Recycle bin** to add and remove fields as needed. > **Note** > > For any other object type other than offered by default, such as Account, Group, Role, and Entitlement, you must manually add the schema and JSON path mapping in the source. Refer to [Best Practices: REST API Authentication](), [REST API - Update Source (Partial)](), and [Adding Attributes to a Source Schema](). 4. If any attribute is Read Only and does not need to be included in the create/update payload, add it to the **Read Only Attributes** list. Attributes listed here will not go on the JSON body. 5. Select **Save**. ## Connector Parameters Configure parameters related to connector operations. Update the parameters to the connector using the SailPoint REST API. > [!NOTE] > > For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication]() and [REST API - Update Source (Partial)]() in the SailPoint Developer Community. > [!NOTE] > > **accessTokenBufferTime** > > Define a span of time in minutes ahead of access token expiration, at which point the connector generates a new access token. This setting is applicable when the access token expiry is less than 10 minutes. Ensure the value you set is not higher than the expiry time. > > Integer (Value should not be in quotes) > > Example configuration: > > ```text > "accessTokenBufferTime": 5 > ``` ## 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. # Integrating SailPoint with SCIM 2.0 SaaS The SCIM (System for Cross-Domain Identity Management) standard defines a schema and API to create, read, update, and delete identity and identity-related information on other systems. This standard creates a common language, by which a client system can communicate with many different servers in the same way. Use the SCIM 2.0 SaaS source to manage identity and access in the SCIM Service provider application. The SCIM 2.0 SaaS source connects to a SCIM Service provider application securely to load data from and provision changes. > [!NOTE] > > To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the [SaaS Release Notes]() page. ## Supported Features Any SCIM 2.0 compliant target system can be managed by using the SCIM 2.0 SaaS source. The SCIM 2.0 SaaS source supports the following features: - Discover Account Schema - Aggregate Accounts - Aggregate Groups - Delta Aggregation - Aggregation Partitioning - Create Account - Account updates - Add and Remove Entitlements - Enable and Disable Accounts - Change Password - Access Certifications (certification of entitlements connected to accounts) - Unlock account > **Note** > > Mapping of the locked status and unlock account operation is supported based on the provided extension attribute. ## Prerequisites The following prerequisites are required: - SailPoint's SCIM 2.0 SaaS source requires the following endpoints with a valid response for connector execution: ```text /ServiceProviderConfig /ResourceTypes /Schemas /ResourceTypes/User /ResourceTypes/Group ``` These endpoints should be defined as per the following RFCs: - [RFC 7643: System for Cross-domain Identity Management: Core Schema]() - [RFC 7644: System for Cross-domain Identity Management: Protocol]() > **Note** > > Not applicable if **Non-Compliant Server** is enabled. - Service accounts used for the SCIM 2.0 SaaS source should have the permissions to perform the following operations: - get all users - modify user - get all groups - modify group membership - Supported Applications - Any application that supports the SCIM 2.0 specification. # Machine Account Attributes ## Machine Account Provisioning Attributes Machine account creation uses a different attribute set than standard account creation. Use the following table to map each machine account attribute to its display name, data type, requirement status, generator, and description. | Attribute | Display Name | Type | Required | Generator | Description | | --- | --- | --- | --- | --- | --- | | userName | Username | string | No | Static | The user's unique name. Enter a unique username for the machine account. | | name.givenName | FirstName | string | No | Disable | The user's first name. | | name.familyName | LastName | string | No | Disable | The user's last name. | | emails.work.primary | Email | string | No | Disable | The user's primary work email address. | | userType | userType | string | No | Disable | The user's classification type within the organization. | ### Classification The Classification attribute is used to identify and categorize the account as a machine account. This connector includes the userType attribute for classification. The generator is Disable by default. - **Attribute name** - UserType - **Value** - Communication, Reference, Service, System For more information, refer to [Machine Identity Security Overview](). # Provisioning Policy The SCIM 2.0 SaaS connector supports provisioning, allowing you to create and manage accounts and entitlements in SCIM 2.0 directly from SailPoint. **Prerequisite:** Your system is configured for provisioning. When SailPoint provisions new accounts to the source, it uses the attributes on the **Create Account** page as instructions or a template for what to include in the account. This page is also referred to as the *provisioning policy*. When new access is granted on a source where a user does not already have an account, SailPoint automatically includes account creation in the provisioning. This applies whether provisioning is started from an access request or from an automated role or lifecycle state assignment. For direct-connect sources, SailPoint automatically creates the account from this configuration. If the source is not configured as a direct-connect source, SailPoint creates and assigns a provisioning task to the source owner and includes the values for the source owner to use in manually creating the account. > [!IMPORTANT] > > This section describes the default **Create Account** configuration. SailPoint recommends that you work with Services to define a provisioning configuration specific to your company's needs. Be sure to verify large changes to the provisioning policy before implementation. Failure to do so might cause provisioning to fail. ## Default Create Account Attributes You can create an account configuration based on a SCIM 2.0 compliant server. The provisioning operation can update the attribute value to a blank value. The SCIM 2.0 SaaS source performs provisioning after regenerating an access token. The SCIM 2.0 SaaS source encodes the JSON during provisioning operations with special characters. > [!CAUTION] > > The SCIM 2.0 SaaS source provides the default Create Account configuration as illustrative purpose. However, SailPoint recommends that you work with Services to define a Create Account configuration specific to your company's needs. | Account Attribute | Generator | Description | | --- | --- | --- | | userName | Disable | The user's unique name. | | name.givenName | Identity Attribute | The user's first name. | | name.familyName | Identity Attribute | The user's last name. | | emails.work.primary | Identity Attribute | The user's primary work email address. | | phoneNumbers.work.primary | Disable | The user's primary work phone number. | | employeeNumber | Disable | The user's employee identifier. | | costCenter | Disable | Cost center associated with the user. | | organization | Disable | The user's organization. | | division | Disable | The user's division. | | department | Disable | The user's department. | | manager.value | Disable | The user's manager's SCIM resource ID. | | manager.displayName | Disable | The user's manager's display name. | # Schema Reference The application schema is used to configure the objects returned from a connector. > [!NOTE] > > - The **Account Schema** tab is used to define the attributes for each object type in the application being configured. The schema attributes can be defined as **Entitlement** or **Multi-Valued**. Refer to [Managing Source Account Schemas]() for more information. > - The schema attributes that are not present by [default](<#default-account-schema>) must be defined as strings if not specified. The SCIM 2.0 SaaS connector uses the following default correlation and object configurations. ## Default Correlation Configuration Before you aggregate accounts from this source, you can map account attributes with their corresponding identity attributes based on your requirements. You can customize the correlation configuration. Refer to [Assigning Source Accounts to Identities]() for more information. When you first create the SCIM 2.0 SaaS source, the default correlation mapping is: | Account Attribute | Operation | Identity Attribute | | --- | --- | --- | | emails.work.primary | Equals | Work Email (email) | | userName | Equals | SailPoint User Name (uid) | | displayName | Equals | displayname | ## Default Account Schema Each source supports a variety of details, or attributes, about each user who has an account, such as their name, email address, manager name, and location. The set of account attributes each source stores and how they're organized is known as the account's *schema*. To best represent your data, you can configure sources to use an account schema matching the one you use in the external connector. Refer to [Managing Source Account Schemas]() for more information. ### Default Account ID SailPoint requires that certain attributes remain in your configuration. These attributes are referred to as *account IDs*. > [!CAUTION] > > Changing the attribute marked as the account ID after aggregating accounts can result in duplicate accounts being created. To avoid this, either reset the accounts on this source before editing the account ID attribute or edit the account ID attribute before aggregating accounts. > > To resolve issues caused by changing account IDs, reconfigure them to their default values. The following table lists the default account IDs for this connector: | Account ID | Schema Object Type | | --- | --- | | id | Account | | id | Group | ### Default Account Attributes The SCIM 2.0 SaaS connector supports the following default account schema attributes and customer configurable attributes. The attributes must be defined as strings if not specified. The SCIM 2.0 SaaS source provides the default Account Schema for illustrative purposes. You can discover the schema from SCIM 2.0 compliant systems using the Discover Schema feature. | Attribute Name | Description | | --- | --- | | active | The user's active status. | | costCenter | Cost center associated with the user. | | department | The user's department. | | displayName | The user's public-facing name. | | division | The user's division. | | emails.home.primary | The user's primary home email address. | | emails.home.secondary | The user's secondary home email address. | | emails.other.primary | The user's alternate email address. | | emails.other.secondary | The user's secondary email address. | | emails.work.primary | The user's primary work email address. | | emails.work.secondary | The user's secondary work email address. | | employeeNumber | The user's employee identifier. | | groups | Groups assigned to the user. | | id | The user's unique ID. | | locale | The user's default location. | | manager.displayName | The user's manager's display name. | | manager.value | The user's manager's SCIM resource ID. | | meta.location | The user's location. | | meta.resourceType | The user's resource type. | | name.familyName | The user's last name. | | name.formatted | The user's full name. | | name.givenName | The user's first name. | | name.middleName | The user's middle name. | | nickName | The user's friendly name. | | organization | The user's organization. | | phoneNumbers.home.primary | The user's primary home phone number. | | phoneNumbers.home.secondary | The user's secondary home phone number. | | phoneNumbers.mobile.primary | The user's primary mobile number. | | phoneNumbers.mobile.secondary | The user's secondary mobile number. | | phoneNumbers.work.primary | The user's primary work phone number. | | phoneNumbers.work.secondary | The user's secondary work phone number. | | preferredLanguage | The user's preferred language. | | profileUrl | The user's online profile URL. | | timezone | The user's Olson time zone format. | | title | The user's title, such as "Vice President". | | userName | The user's unique name. | | userType | The user's classification type within the organization. | ## Default Entitlement Attributes Entitlement attributes define the entitlements, such as groups or roles, that can be assigned to the managed system's user accounts. Refer to [Managing Entitlements]() for more information. > [!CAUTION] > > Changing the attribute marked as the Entitlement ID after aggregating accounts or entitlements can result in duplicate entitlements being created, or access profiles and roles breaking. To avoid this, edit the entitlement schema before performing any aggregations. | Attribute Name | Description | | --- | --- | | displayName | The name of the group, suitable for display. | | id | Unique identifier for the resource as defined by the SCIM service provider. | | members | The count of user membership. | | meta.created | Created date time. | | meta.lastModified | Last modified date time. | # Troubleshooting If you encounter any of the following issues or errors, SailPoint recommends that you follow the guidance provided below to resolve the error before contacting SailPoint Support. For issues or errors that are not addressed in this connector guide, refer to the following resources for troubleshooting information: - [SailPoint Identity Services Documentation]() - [SailPoint Support Knowledge Base]() - [SailPoint Developer Community]() ## Debug Logs For information about managing additional source settings, including debug logging and downloading connector logs, refer to [Managing Additional Settings](). ## Create account operation fails while using recommended mappings in the Account Policy The create account operation fails even though the recommended attribute mappings are used in the Account Policy. **Resolution** - Ensure that the managed system is enabled to set the account attributes used by the Account Policy, then try the Create account operation again. ## Attribute values in Compliant Settings are not populated after aggregation and/or provisioning processes You try to add a new attribute to Compliant Settings from the SCIM server endpoint schema to the account schema, but aggregation processes don't fetch the attribute value, and/or provisioning processes don't send the attribute to the managed system. **Resolution** - Perform a [Discover Source]() operation, and then run an unoptimized account aggregation. ## Extended schema attributes for Group objects are not aggregated Additional attributes added for Group objects are not included in entitlement aggregation. **Resolution**: - **Compliant** - Add the required attributes to the group object schema and run an entitlement aggregation process. - **Non-Compliant** - Add the required attributes to the group object schema, and also properly map their respective JSON paths in the source, then run an entitlement aggregation process. ## Test connections fail with 401 Unauthorized errors **Issue** - Test connections fail with the following error: ```text 401 Unauthorized using grant type as - Client Credentials ``` **Cause** - Some SCIM servers require additional Headers for token generation to support client credentials as a grant type. **Resolution** - Add the following to the OAuth Headers configuration in the connector: **Key** - `Authorization` **Value** - `Basic clientId:ClientSecret (base64 Encoded)` For more information, refer to [Client Credentials](). ## Connector fails to accept 204 No Content for PATCH requests **Issue** - The SCIM 2.0 SaaS connector does not accept a `204 No Content` response for PATCH requests. **Resolution** - Enable `acceptEmptyResponseForPatchCall` flag in application xml. `acceptEmptyResponseForPatchCall` flag is used to handle SCIM targets that return empty response bodies such as a `204 No Content` status code for PATCH requests. ## PATCH operations for core attributes omit the path **Issue** - The SCIM 2.0 SaaS connector sends PATCH requests for core attributes such as `name.givenName` and `name.familyName` using a value-based format without an explicit path. Example payload: ```json { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [ { "op": "replace", "value": { "name": { "givenName": "KC" } } } ] } ``` **Resolution** - Enable the `includePathForCoreAttributes: true` flag in the application XML using the REST API, then re-run the attribute sync operation. The connector then uses an explicit path format for PATCH operations on core attributes. Example payload with the flag enabled: ```json { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [ { "op": "replace", "path": "name.familyName", "value": "Nabel" } ] } ```