# SailPoint Oracle Access Governance Connector Documentation

> Oracle Access Governance Connector Documentation

# Documentation

# Connecting SailPoint and Oracle Access Governance

To connect SailPoint with Oracle Access Governance, 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](<https://documentation.sailpoint.com/connectors/help/credential_providers.html>). 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](<https://documentation.sailpoint.com/connectors/help/credential_providers.html>).
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](<https://documentation.sailpoint.com/saas/help/sources/index.html#assigning-a-source-owner>).
4. (Optional) Select a governance group to grant its members [source](<https://documentation.sailpoint.com/saas/help/common/users/user_levels.html#source-sub-admin-user-level>) or [role](<https://documentation.sailpoint.com/saas/help/common/users/user_levels.html#role-sub-admin-user-level>) sub-admin level oversight of the source and its access. For more information, refer to [Creating and Managing Governance Groups](<https://documentation.sailpoint.com/saas/help/common/users/governance_groups.html>).
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](<https://documentation.sailpoint.com/saas/help/setup/identity_profiles.html>).
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](<https://documentation.sailpoint.com/connectors/help/credential_providers.html>).
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](<https://documentation.sailpoint.com/saas/help/common/users/governance_groups.html#associating-a-governance-group-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

Enter the information that the source uses to connect to Oracle Access Governance and authenticate with OCI IAM.

> [!NOTE]
>
> **Screenshot**
>
> [![Connection Settings fields for Service Instance URL, OCI IAM Domain URL, Client ID, and Client Secret](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/img/connection_settings.png>)](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/img/connection_settings.png>)

1. In **Service Instance URL**, enter the base URL of the Oracle Access Governance service instance, such as `https://example.access-governance.region.oci.oraclecloud.com`.
2. In **OCI IAM Domain URL**, enter the base URL of the OCI IAM identity domain, such as `https://idcs-example.identity.oraclecloud.com`. You can also enter the full URL ending in `/oauth2/v1/token`.
3. In **Client ID**, enter the client ID of the confidential application.
4. In **Client Secret**, enter the client secret of the confidential application. The secret is stored encrypted and is not written to logs.
5. Select **Save**.

## Aggregation Settings

> [!NOTE]
>
> **Screenshot**
>
> [![Aggregation Settings fields for Page Size, Aggregate Only Active Identities, Enable Partitioning, and Number of Partitioning Threads](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/img/aggregation_settings.png>)](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/img/aggregation_settings.png>)

1. Select the **Enable Partitioning** toggle to divide account aggregation across concurrent threads.

   Leave partitioning disabled for small tenants. Each thread reads the identities assigned to it, so using too many partitions can increase the number of API requests.
2. In **Number of Partitioning Threads**, enter a value from `1` through `4`.

   Oracle Access Governance limits the tenant to four concurrent requests. Requests beyond this limit can receive a backoff of approximately 40 seconds. The connector does not use more than four threads, even if a higher value is entered.
3. Select **Save**.

## Provisioning Settings

Set how long SailPoint waits for Oracle Access Governance to finish an access request before it reports the request as failed.

> [!NOTE]
>
> **Screenshot**
>
> [![Provisioning Settings field for Provisioning Retry Attempts](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/img/provisioning_settings.png>)](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/img/provisioning_settings.png>)

1. In **Provisioning Retry Attempts**, enter how many times SailPoint checks an access request that Oracle Access Governance has not finished. Enter a value from `1` through `23`. The default is `20`.

   Checks run once an hour, so this value is how many hours an approver has before SailPoint reports the request as failed.

   > **Note**
   >
   > The maximum is 23 because Oracle Access Governance no longer recognizes the earlier request after 24 hours. A later check would submit a duplicate request.
2. Select **Save**.

For more information about how Oracle Access Governance completes requests, refer to [Provisioning Behavior](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/provisioning.html>).

## 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](<https://documentation.sailpoint.com/saas/help/ai/app_onboarding/index.html>) in the SailPoint SaaS documentation.

# Integrating SailPoint with Oracle Access Governance

Oracle Access Governance is a cloud-based identity governance and administration service on Oracle Cloud Infrastructure. It connects to applications as orchestrated systems and manages access through access bundles and roles.

Use the Oracle Access Governance connector to aggregate identities as accounts and roles and access bundles as entitlements. The connector also aggregates direct permissions and supports entitlement grants and revocations and account enable and disable operations.

Each SailPoint source connects to one Oracle Access Governance service instance.

> [!NOTE]
>
> To view the latest features, enhancements, and fixes for all SaaS connectors, refer to the [SaaS Release Notes](<https://community.sailpoint.com/release-notes/saas>) page.

## Supported Features

| Feature | Description |
| --- | --- |
| Test connection | Validates the Oracle Access Governance and OCI IAM configuration. |
| Account aggregation | Aggregates Oracle Access Governance identities as accounts, including their direct permissions. |
| Account read | Reads an Oracle Access Governance identity by ID. |
| Entitlement aggregation | Aggregates Oracle Access Governance roles and access bundles as entitlements. |
| Add entitlement | Grants a role or access bundle to an identity. |
| Remove entitlement | Revokes a role or access bundle from an identity. |
| Enable and disable account | Enables or disables an identity or its account on an orchestrated system. |

## Prerequisites

Before you configure the Oracle Access Governance source, ensure you have:

- An Oracle Access Governance Premium license. The connector uses the Oracle Access Governance REST APIs, which require a Premium license. For more information, refer to [Oracle Access Governance REST APIs](<https://docs.oracle.com/en/cloud/paas/access-governance/restapi.html>) in the Oracle documentation.
- An Oracle Access Governance service instance.
- Orchestrated systems onboarded and loaded in the service instance. Identities, roles, and access bundles aggregate from the instance. The applications an identity has access on come from its permissions. An instance with no orchestrated systems loaded aggregates identities and little else.
- An OCI IAM identity domain that can issue access tokens for the Oracle Access Governance service instance.
- A confidential application in the OCI IAM identity domain.
- The client ID and client secret for the confidential application.
- A token issuance policy that includes the Oracle Access Governance resource and required scope.
- A supported Oracle Access Governance application role assigned to the confidential application. Refer to [Required Permissions](<#required-permissions>).

Create one SailPoint source for each Oracle Access Governance service instance. Each instance is bound to a single OCI tenancy and identity domain. No Oracle Access Governance API spans instances.

A virtual appliance is not required. The connector runs on SaaS Connectivity and calls Oracle Access Governance over HTTPS. The service instance URL and identity domain URL must be publicly resolvable.

Before you go live, configure **No Approval Required** on Oracle Access Governance roles and access bundles that SailPoint must grant immediately. Refer to [Provisioning Behavior](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/provisioning.html>).

For more information, refer to [Configuration Prerequisites](<https://docs.oracle.com/en/cloud/paas/access-governance/pmapi/prerequisites.html>) in the Oracle documentation.

> [!NOTE]
>
> The linked document is not maintained by SailPoint and is subject to change without notice.

### Configuring the Confidential Application

Oracle documents how to create the confidential application in [Before You Begin: Key Prerequisites for Configuration](<https://docs.oracle.com/en/cloud/paas/access-governance/pmapi/prerequisites.html>).

The connector requires the following from that application:

- The client credentials grant type only. Oracle offers additional grant types and suggests authorization code for create, update, and delete operations. The connector authenticates with no user present and does not need a redirect URL, so client credentials is the correct grant type.
- The Oracle Access Governance service instance added as a resource, which yields the scope `<Service Instance URL>/urn:opc:agcs:all`. Adding the resource places it in the application's token issuance policy. Without that resource, a token is still issued and then rejected, and Test Connection fails.
- An **Active** status. A confidential application is created inactive and issues no token until you activate it.
- An Oracle Access Governance application role assigned to it. Assign `AG_Administrator` to provision, or `AG_Auditor` for a read-only source. Refer to [Required Permissions](<#required-permissions>).
- The client ID and client secret for the application. These are two of the four values the source requires.

## Required Permissions

Assign an Oracle Access Governance application role to the confidential application based on the operations the source performs.

| Connector Operation | Minimum Application Role |
| --- | --- |
| Test connection | `AG_Auditor` |
| Account aggregation | `AG_Auditor` |
| Entitlement aggregation | `AG_Auditor` |
| Add entitlement | `AG_Auditor` |
| Remove entitlement | `AG_Administrator` |
| Enable or disable an identity or account | `AG_Administrator` |

> [!NOTE]
>
> **Best Practice**
>
> Assign `AG_Administrator` when the source performs aggregation and provisioning. This is the only predefined role that supports both operation types.

For a read-only source, assign `AG_Auditor`. This role supports account, entitlement, and direct permission aggregation without administrator privileges.

Revocation admits only `AG_Administrator` or `AG_ServiceDesk_Admin`. `AG_ServiceDesk_Admin` cannot read the role and access bundle catalogs that aggregation requires.

In Oracle Cloud Infrastructure, go to **Identity &amp; Security \> Domains \> your domain \> Oracle Cloud Services \> your Oracle Access Governance service instance \> Application roles \> Manage applications \> Assign applications** to assign the role.

For more information, refer to [Application Roles](<https://docs.oracle.com/en-us/iaas/Content/access-governance/about-application-roles.htm>) in the Oracle documentation.

> [!NOTE]
>
> The linked document is not maintained by SailPoint and is subject to change without notice.

# Provisioning Behavior

## Asynchronous Provisioning

Oracle Access Governance processes provisioning requests asynchronously. It accepts a request immediately and completes it later. Role requests typically take one to two minutes. Access bundle requests might take longer.

After Oracle Access Governance accepts a request, the connector reports the operation as pending. SailPoint checks the operation approximately once an hour and closes the request after Oracle Access Governance completes it.

- The request in SailPoint might remain pending for up to an hour after Oracle Access Governance grants the access.
- The account reflects the new access after the next account aggregation.
- If an approval takes longer than the retry allowance, SailPoint might report the request as failed even if Oracle Access Governance completes it later.

## Approval Workflows

Oracle Access Governance roles and access bundles can use approval workflows. When an approval workflow is configured, a request from SailPoint remains in progress until an Oracle Access Governance approver acts.

Configure **No Approval Required** on roles and access bundles that must be granted immediately from SailPoint.

If approvals routinely exceed the retry allowance, increase **Provisioning Retry Attempts** on [Provisioning Settings](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/connecting.html#provisioning-settings>).

## Provisioning Attributes

The connector does not create accounts and does not write account attributes.

Oracle Access Governance creates and maintains accounts from the authoritative sources that feed it. Provisioning from SailPoint is limited to granting and revoking roles and access bundles, and to enabling and disabling an account at identity level or per orchestrated system. The connector rejects attempts to set other account attributes.

# 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](<https://documentation.sailpoint.com/saas/help/accounts/schema.html>) for more information.
> - The schema attributes that are not present by [default](<#default-account-schema>) must be defined as strings if not specified.

The Oracle Access Governance 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](<https://documentation.sailpoint.com/saas/help/accounts/correlation.html>) for more information.

When you first create the Oracle Access Governance source, the default correlation mapping is:

| Account Attribute | Operation | Identity Attribute |
| --- | --- | --- |
| `email` | Equals, ignoring case | Email |

## 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](<https://documentation.sailpoint.com/saas/help/accounts/schema.html>) for more information.

### Default Account Attributes

The Oracle Access Governance connector supports the following default account schema attributes and customer configurable attributes. The attributes must be defined as strings if not specified.

The account schema represents Oracle Access Governance identities. The identity attribute is `id`, and the display attribute is `displayName`.

| Attribute Name | Description |
| --- | --- |
| `id` | Unique Oracle Access Governance identity ID. |
| `displayName` | Display name of the identity. When no display name is available, the connector uses the sign-in name. |
| `email` | Email address of the identity. This is the default correlation attribute. |
| `status` | Status of the identity in title case, such as `Active`. |
| `connectedApplications` | Orchestrated systems where the identity has access. |
| `roles` | Native IDs of the roles assigned to the identity. |
| `accessBundles` | Native IDs of the access bundles assigned directly to the identity. The connector omits bundles granted through a role because Oracle Access Governance does not allow them to be revoked individually. |
| `expiringSoonAccess` | Access that Oracle Access Governance identifies as expiring soon. Each value uses the format `name :: expiry :: status`. The attribute is empty when access is indefinite or has not entered its configured notification window. |

#### Direct Permissions

The connector displays permissions assigned directly to an identity in the read-only **Direct Permissions** view. Each entry identifies the orchestrated system as the target and the permission title as the right. Direct permissions are not entitlements and cannot be requested or revoked from SailPoint.

## 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](<https://documentation.sailpoint.com/saas/help/access/entitlements.html>) 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.

### Default Role Attributes

The Oracle Access Governance connector supports roles. The following attributes must be configured on the managed system and in the SailPoint source schema to manage roles.

The role entitlement represents an Oracle Access Governance role. The identity attribute is `id`, and the display attribute is `name`.

| Attribute Name | Description |
| --- | --- |
| `id` | Native ID of the role. |
| `name` | Name of the role. Role names are unique within Oracle Access Governance. |
| `description` | Description of the role. The connector provides a generated description when Oracle Access Governance does not return one. |
| `applications` | Distinct applications associated with the role's access bundles. |
| `includedAccessBundles` | Access bundles included in the role. Each value uses the format `BundleName (ApplicationName)`. |
| `includedPermissions` | Permissions granted by the role. Each value uses the format `Application / Bundle :: Permission`. |

### Access Bundle Attributes

The access bundle entitlement represents an Oracle Access Governance access bundle. The identity attribute is `id`, and the display attribute is `displayName`.

| Attribute Name | Description |
| --- | --- |
| `id` | Native ID of the access bundle. |
| `name` | Name of the access bundle. The name might not be unique across applications. |
| `displayName` | Qualified display name in the format `BundleName (ApplicationName)`. |
| `description` | Description of the access bundle. The connector provides a generated description when Oracle Access Governance does not return one. |
| `applications` | Application that owns the access bundle. |
| `includedPermissions` | Permissions included in the access bundle. Each value uses the format `Application / Permission :: Context=Value`. |
| `accessTimeLimit` | Length of time the access bundle grants access, such as `365 days` or `1 hour`. The value is `Indefinite` when no time limit is configured. |
| `expiryNotification` | How long before expiration Oracle Access Governance identifies the access as expiring soon. The value is `None` when no notification window is configured. |
| `accessExtension` | Whether access can be extended beyond its time limit, such as `Up to 90 days`. The value is `None` when extensions are not available. |

# 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](<https://documentation.sailpoint.com/saas/help/index.html>)
- [SailPoint Support Knowledge Base](<https://support.sailpoint.com/csm?id=kb_view2&amp;kb_id=05ff44289f011200550bf7b6077fcfa3>)
- [SailPoint Developer Community](<https://developer.sailpoint.com/>)

## Debug Logs

For information about managing additional source settings, including debug logging and downloading connector logs, refer to [Managing Additional Settings](<https://documentation.sailpoint.com/saas/help/sources/managing_additional_settings.html>).

## Test connection reports a token issuance policy error

**Resolution** - Add the Oracle Access Governance resource and required scope to the confidential application's token issuance policy.

## Test connection reports a credentials error, but the client ID and client secret are correct

**Resolution** - Go to **Identity &amp; Security \> Domains \> your domain \> Integrated applications** and activate the confidential application from the **Actions** menu. The status must be **Active**. OCI IAM creates confidential applications as inactive, and an inactive application does not issue a token.

## An operation reports insufficient privileges

**Resolution** - Assign `AG_Administrator`, or assign `AG_Auditor` for a read-only source. Refer to [Required Permissions](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/index.html#required-permissions>).

## Aggregation or provisioning intermittently reports rate limiting

**Resolution** - The connector retries throttled requests with backoff. If the issue continues, reduce the aggregation frequency.

## Test connection reports an unreachable host

**Resolution** - Verify **Service Instance URL** and **OCI IAM Domain URL**, and confirm both services are reachable.

## An access request remains pending

**Resolution** - Review the request in Oracle Access Governance. An approval workflow might be waiting for action, or SailPoint might not have checked the operation yet. If approvals routinely exceed the retry allowance, increase **Provisioning Retry Attempts** on [Provisioning Settings](<https://documentation.sailpoint.com/connectors/oracle/access_governance/saas/help/connecting.html#provisioning-settings>).

## Provisioning fails without a reason

**Resolution** - Open the request in Oracle Access Governance. Check the orchestrated system's connection and most recent data load.

## Entitlements aggregate but identities show no access

**Resolution** - Run an account aggregation after the entitlement aggregation.

# Timeout Errors and Settings

Timeout errors might occur when SailPoint is waiting for a response from the connector-runtime. These errors are applicable to all connectors and tend to occur during the setup of sources or when sources are down.

This document is designed to give specific information that can be used to resolve these errors.

Each timeout attribute has a default time value that is listed in seconds or minutes. Increasing the time value may resolve the error as it will allow for longer communication time between the two systems, thus avoiding the timeout error.

To increase the communication time, increase the value of the appropriate timeout attribute. Then submit the change to the connector-runtime using the SailPoint REST API.

> [!NOTE]
>
> For more information on SailPoint's REST APIs, refer to [Best Practices: REST API Authentication](<https://developer.sailpoint.com/docs/api/authentication/>) and [REST API - Update Source (Partial)](<https://developer.sailpoint.com/docs/api/update-source-v-1/>) in the SailPoint Developer Community.

### aggregateTimeout

**Description:** This parameter is set for the aggregation timeout, measured in seconds.

**Resolution:** Increase the `aggregateTimeout` value gradually to optimize aggregation. Start with 180, then increase to 600, 900, and finally 1800. The maximum value is 3600 seconds.

For example:

If your current time value is 180 seconds, update the `aggregateTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/aggregateTimeout",
        "value": 600
    }
]
```

### healthCheckTimeout

**Description:** This parameter is set for the test connection and health check timeout.

**Resolution:** The default value is 30 seconds. If the timeout error continues, increase the value in 15 second increments and try again.

For example:

If your current time value is 30 seconds, update the `healthCheckTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/healthCheckTimeout",
        "value": 45
    }
]
```

### provisioningTimeout

**Description:** This parameter is set for provisioning timeout.

**Resolution:** Increase the `provisioningTimeout` value gradually to optimize provisioning. Start with 180, then increase to 360, and finally 600. The maximum value is 600 seconds.

For example:

If your current time value is 180 seconds, update the `provisioningTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/provisioningTimeout",
        "value": 360
    }
]
```

### timeout

**Description:** This parameter is set for pass-through authentication timeout.

**Resolution:** The default value is 15 seconds. If the timeout error continues, increase this value in 15 second increments and try again.

For example:

If your current time value is 15 seconds, update the `timeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/timeout",
        "value": 30
    }
]
```

### apiTimeout

**Description:** This parameter is set for API time tracking; customers can check it using an external tool.

**Resolution:** The default value is 60 seconds. If the error continues, increase the value by 15 second increments and try again.

For example:

If your current time value is 60 seconds, update the `apiTimeout` attribute as follows:

```json
[
    {
        "op": "replace",
        "path": "/connectorAttributes/apiTimeout",
        "value": "75"
    }
]
```