Additional Settings

This section includes information for configuring custom headers for OAuth 2.0 No Authentication configurations, optional OAuth 2.0 parameters, as well as information on provisioning settings. Use this information to further customize your connector.

HTTP Request Headers

You have several options to configure HTTP headers as needed for your organization.

Configure the HTTP Content-type header value that you can use for the SCIM requests. The default value is application/scim+json.
In the Accept field enter the HTTP Accept header value that you can use for the SCIM requests. The default value is application/scim+json. The SCIM 2.0 source does not include the read-only attributes in HTTP PATCH requests.

OAuth Settings

Configure additional OAuth settings.

To send headers required for the No Authentication type, add a header key and its corresponding value into the No Authentication Headers sub-panel in the OAuth Settings section.

For example, you can add customParamKey and the corresponding customParamValue:
Copy
```
<entry key="noAuthHeaders">
    <value>
        <Map>
            <entry key="customParamKey" value="customParamValue"/>
            <entry key="password" value="$application.password_CA$"/>
        </Map>
    </value>
</entry>
```
Caution

Don't configure sensitive attributes through the No Authentication Headers sub-panel in the UI configuration. They should be added through the Update Source Partial REST API and used with placeholders. When you add sensitive attributes to the headers, ensure that the attributes are added with the suffix, _CA. If the attributes are not suffixed with _CA, the SCIM 2.0 source might display unusual behavior. For more information on using the Update Source Partial REST API, see REST API - Update Source (Partial).

For example, to use a password in the header value, add the password_CA attribute using the source API and use $application.password_CA$ in header value. If the attribute updated is a password then it must be added to the header as follows:

Before updating the encrypted list:

{"encrypted":"refresh_token,oauthTokenInfo,client_secret,oauthBearerToken,additional_payload,private_key, private_key_password,oauth2password,noAuthHeaders"}

After updating the encrypted list:

{"encrypted":"refresh_token,oauthTokenInfo,client_secret,oauthBearerToken,additional_payload,private_key, private_key_password,oauth2password,noAuthHeaders,password_CA"}
To send additional parameters for token generation in the OAuth 2.0 Authentication type, in the OAuth Request Parameters sub-panel panel in the OAuth Settings section, you can add a key and its corresponding value.

For example, you can add Content-Type as key and the corresponding value as application/x-www-form-urlencoded.
If you want to set up and add expected errors while generating a token, enter a list of retryable errors in the Retryable Errors field in the OAuth Settings section.

For example, you can use "unauthorized", "401", "does not have access"

(Optional) Set the following parameters only when the Authentication Method is selected as OAuth2 and the Grant Type is either Client Credentials or Refresh Token. These parameters should be added through the Update Source Partial 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.

oauth_headers

To have customized headers as a part of the access token generation request, add the oauth_headers parameter as follows:

Copy

<entry key="oauth_headers">
    <value>
        <Map>
            <entry key="Content-Type" value="application/x-www-form-urlencoded" />
        </Map>
    </value>
</entry>

To send additional headers alongside the Authorization header for token generation, add the oauth_headers parameter as follows:

Copy

<entry key="oauth_headers">
    <value>
        <Map>
            <entry key="customHeaderKey" value="customHeaderValue"/>
        </Map>
    </value>
</entry>

oauth_headers_to_exclude

SCIM 2.0 supports exclusion of headers in the OAuth2 header request. The keys for headers to exclude from the OAuth2 header request can be added as comma-separated values in the entry key as follows:

Copy

<entry key="oauth_headers">
    <value>
        <Map>
            <entry key="oauth_headers_to_exclude" value="Authorization,CUSTOM_HEADER"/>
        </Map>
    </value>
</entry>

oauth_request_parameters

For some managed systems, additional custom request parameters may be required to be included in the access token generation request. To send additional parameters for token generation, add the following entry with your desired parameters:

Copy

<entry key="oauth_request_parameters">
    <value>
        <Map>
            <entry key="customParamKey" value="customParamValue"/>
        </Map>
    </value>
</entry>

oauth_body_attrs_to_exclude

To delete any of the standard request parameters not supported by managed systems access token generation requests, add the following entry with your desired parameters:

Copy

<entry key="oauth_body_attrs_to_exclude">
    <value>
        <Map>
            <entry key="oauth_body_attrs_to_exclude"
            value="customParamKey1,customParamKey2"/>
        </Map>
    </value>
</entry>

Provisioning Settings

Configure additional settings related to provisioning processes.

Enable the USE HTTP PATCH method if usePatch is required. While updating the existing attributes, the SCIM 2.0 source supports the Replacing operation instead of Adding, while using the PATCH method.
Enable Skip Group Update to skip the redundant group update call, and instead, to use a create account with entitlement request. The default behavior of SCIM 2.0 is to communicate with the Groups endpoint for modification of groups information, but you can configure the source to modify group information through the Users endpoint. To enable this feature, set the updateGroupsViaUsers attribute to true in the source XML file using the REST API.

<entry key="updateGroupsViaUsers" value="true"/>)

Note
Refer to Best Practices: REST API Authentication and REST API - Update Source (Partial) for more information on configuring via the REST API.

When enabled, the SCIM 2.0 source adds all the attributes in the create/upload payload regardless of its mutability. If any attributes are read-only, and should not be included in the create/update payload, add them in a list. For example:
Copy
```
<entry key="readOnlyAttrs">
    <Value>
        <List>
            <String>groups</String>
            <String>federationId</String>
        </List>
    </Value>
</entry>
```

Enable Multivalued RFC Compatibility to generate a more consolidated JSON format. This format is needed to provision multivalued extended schema attributes in a relaxed configuration.

Example

The following examples are for a multivalued extended schema attribute representing a user's address.

When Multivalued RFC Compatibility is disabled, the JSON is generated as follows:

Copy

"addresses": [
        {
            "country": "USA",
            "type": "work",
            "primary": true
        },
        {
            "locality": "Grand Island",
            "type": "work",
            "primary": true
        },
        {
            "type": "work",
            "region": "USA-NE",
            "primary": true
        }
    ]

When Multivalued RFC Compatibility is enabled, the JSON is generated as follows:

Copy

"addresses": [
        {
        "type": "work",
        "locality": "Austin",
        "region": "TX",
        "country": "USA",
        "primary": true
        }
    ]

To send the path for a Simple Core Complex Attribute during an HTTP request, enable the includePathForCoreAttributes parameter in the source XML via REST API as follows:

<entry key="includePathForCoreAttributes" 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.

Simple Core Complex Attributes include attributes such as name.familyName or name.givenName.

Feedback is provided as an informational resource only and does not form part of SailPoint's official product documentation. SailPoint does not warrant or make any guarantees about the feedback (including without limitation as to its accuracy, relevance, or reliability). All feedback is subject to the terms set forth at https://developer.sailpoint.com/discuss/tos.

Additional Settings

HTTP Request Headers

OAuth Settings

Provisioning Settings

Documentation Feedback