# Provisioning for Okta

### Overview

The Veza integration for Okta enables user provisioning and deprovisioning, with support for group membership management and attribute synchronization.

| Action Type           | Description                                                                                                      | Supported |
| --------------------- | ---------------------------------------------------------------------------------------------------------------- | --------- |
| SYNC\_IDENTITIES      | Synchronizes identity attributes between systems, with options to create new identities and update existing ones | ✅         |
| MANAGE\_RELATIONSHIPS | Controls entitlements such as group memberships and role assignments for identities                              | ✅         |
| DEPROVISION\_IDENTITY | Safely removes or disables access for identities, includes user logout support                                   | ✅         |
| DELETE\_IDENTITY      | Permanently removes the user account from Okta                                                                   | ✅         |
| CREATE\_ENTITLEMENT   | Creates entitlements such as Okta groups                                                                         | ✅         |
| RESET\_PASSWORD       | Allows password reset operations for Okta users                                                                  | ✅         |
| SOURCE\_OF\_IDENTITY  | Okta can act as a source system for identity lifecycle policies                                                  | ✅         |

This document includes steps to enable the Okta integration for provisioning, along with supported actions and notes. See [Supported Actions](#supported-actions) for more details.

### Enabling provisioning

#### Prerequisites

1. You will need administrative access in Veza to configure the integration and grant API scopes in Okta.
2. Ensure you have an existing [Okta integration](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta.md) in Veza or add a new one for use with provisioning.
3. Verify your Okta integration has completed at least one successful extraction
4. The Okta integration will need the additional required API scopes:
   * `okta.users.manage` - For user lifecycle operations
   * `okta.groups.manage` - For group membership management

> **Enhanced Security**: For organizations with security policies preventing super admin grants, see the [Okta custom admin role setup guide](/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta.md#admin-role-requirements) which provides least-privilege alternatives that include these additional scopes.

#### Configuration Steps

To enable the integration:

1. In Veza, go to the **Integrations** overview
2. Search for or create an Okta integration
3. Check the box to **Enable usage for Provisioning**

Configure the extraction schedule to ensure your Okta data remains current:

1. Go to Veza **Administration** > **System Settings**
2. In **Pipeline** > **Extraction Interval**, set your preferred interval
3. Optionally, set a custom override for Okta in the *Active Overrides* section

To verify the health of the provisioning data source:

1. Open **Lifecycle Management** > **Integrations** (in the Products section of the navigation sidebar), or the main **Integrations** page (in the Featured section)
2. Search for the integration and click the name to view details
3. In the **Properties** panel, click the magnifying glass icon under **Lifecycle Management Enabled**

### Supported Actions

Okta can serve as a *source* for identity information in Lifecycle Management [Policies](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/policies.md). User identity details are synchronized from Okta with changes propagated to connected systems.

Okta can also be a *target* for identity management actions, based on changes in another external source of truth or as part of a workflow:

The integration supports the following [Actions](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/actions.md):

#### Sync Identities

Primary action for user management (creating or updating users):

* Login ID cannot be changed after creation
* Email addresses must be unique
* Required attributes must be present (login, email, first\_name, last\_name)

The following attributes can be synchronized:

<details>

<summary>Okta User Attributes</summary>

| Property      | Required | Type   | Description               | Notes             |
| ------------- | -------- | ------ | ------------------------- | ----------------- |
| login         | Yes      | String | Primary login identifier  | Unique identifier |
| email         | Yes      | String | User's email address      | Unique            |
| first\_name   | Yes      | String | Given name                |                   |
| last\_name    | Yes      | String | Family name               |                   |
| display\_name | No       | String | User's display name       |                   |
| user\_type    | No       | String | User type                 |                   |
| department    | No       | String | Organizational department |                   |
| title         | No       | String | Job title                 |                   |
| manager       | No       | String | Manager's name            |                   |
| manager\_id   | No       | String | Manager's identifier      |                   |
| employee\_id  | No       | String | Employee identifier       |                   |
| division      | No       | String | Business division         |                   |
| organization  | No       | String | Organization name         |                   |
| cost\_center  | No       | String | Cost center               |                   |
| country\_code | No       | String | Country code              |                   |
| second\_email | No       | String | Secondary email address   |                   |
| nickName      | No       | String | User's nickname           |                   |

</details>

#### Manage Relationships

Both adding and removing memberships are supported. Group memberships are removed in deprovisioning.

* Add and remove group memberships
* Synchronize group assignments
* Track membership changes

#### Deprovision Identity

When a user is deprovisioned:

* User account is disabled or suspended
* Group memberships are removed
* Attribute history is preserved for audit
* Account can be reactivated if needed

#### Create Entitlement

* **Entity Types:** Okta Groups
* **Assignee Types:** Okta Users
* **Supports Relationship Removal:** Yes

Within Okta, groups can be associated with:

* Application group assignments controlling SSO access
* Permissions to resources within specific applications
* Synchronized AWS SSO groups
* Role-based access controls within Okta

<details>

<summary>Okta Group Attributes</summary>

| Property                      | Required | Type      | Description                 |
| ----------------------------- | -------- | --------- | --------------------------- |
| unique\_id                    | Yes      | String    | Group identifier            |
| description                   | No       | String    | Group description           |
| type                          | No       | String    | Group type                  |
| source                        | No       | String    | Group source                |
| last\_membership\_updated\_at | No       | Timestamp | Last membership update time |

</details>

#### Reset Password

Resets passwords for Okta users by expiring their current password and generating a temporary password:

* Requires the `login` attribute as a unique identifier
* Non-idempotent action (each execution creates a new password reset event)
* Expires the user's current password immediately
* Returns an Okta-generated temporary password
* Any password provided in the request is ignored; Okta always generates the temporary password
* The user must sign in with the temporary password and will be prompted to set a new permanent password

{% hint style="info" %}
The temporary password is available in notification templates using the `{{LOGIN_PASSWORD}}` placeholder. Configure a notification for the `LIFECYCLE_MANAGEMENT_RESET_PASSWORD` event to automatically send the temporary password to users through your organization's approved channels. See [Notification Templates](/4yItIzMvkpAvMVFAamTf/features/lifecycle-management/policies-workflows/lifecycle-management-notification-templates.md) for details.
{% endhint %}

#### Delete Identity

Permanently removes a user from Okta:

* **Entity Type:** Okta User
* **Action:** User account is permanently deleted from Okta
* **Removes All Relationships:** Yes — all group memberships are removed automatically

**Limitations:**

* Permanent and cannot be undone
* Use `DEPROVISION_IDENTITY` instead when temporary removal or reactivation may be needed


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/integrations/integrations/okta/provisioning.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.