Overview

Veza can automate user provisioning and de-provisioning for any application that uses the Open Authorization API (OAA) for data gathering and authorization modeling, and exposes SCIM-compliant endpoints for user and group management.

This enables organizations to:

• Use your application's existing SCIM endpoints for automated provisioning operations

• Model complex authorization structures using OAA's flexible templates (applications, resources, permissions, custom properties) for Access Graph visibility, Access Reviews, and other Veza features.

• Gather authorization metadata using a variety of methods (custom connectors, APIs, manual JSON payloads, CSV files)

1. Administrative access in Veza to configure the integration

2. An existing integration in Veza with at least one successful extraction

3. Your custom application must expose SCIM 2.0-compliant endpoints; see below

4. SCIM connection details for the custom application (URL, authentication credentials)

To enable the integration:

1. In Veza, go to the Integrations overview

2. Search for your custom OAA application integration

3. Check the box to Enable usage for Provisioning

To verify the configuration:

1. Open Lifecycle Management > Integrations

2. Search for the integration and click to view details

3. In the Properties sidebar on the right (not the Properties tab), verify that Provisioning Support shows Enabled

There are several potential ways to integrate a custom application for automated lifecycle management and access requests:

1. External SCIM for Open Authorization API: You may build your OAA integration using the custom application template and leverage dedicated SCIM endpoints for user and group management. This is useful when you need full control over how authorization metadata is represented in the Veza Access Graph:

   • Your application supports SCIM, and you want to model a wider range of authorization entities and metadata (e.g., credentials, resources) than the Veza SCIM integration supports.

   • You already have a custom OAA integration and want to add provisioning capabilities using SCIM.

This document describes how to enable External SCIM for an Open Authorization API integration, and supported actions.

Data Gathering (OAA):

You will need to design and build a custom integration to publish information about the application to the Veza Access Graph:

• The payload can include local users, groups, permissions, resources, and complex authorization relationships

• Data can be gathered from any source: APIs, databases, configuration files, etc.

See the rest of the Open Authorization API documentation for examples and best practices when designing and deploying custom integrations.

Lifecycle Management (SCIM):

You can enable the SCIM connection at the custom provider level:

• Setting provisioning: true and external_lifecycle_management_type: SCIM for the custom provider enables Veza to use your application's SCIM endpoints for provisioning

• Provide SCIM connection information and credentials (configuration_json)

• Veza maps lifecycle actions to SCIM operations (POST /Users

Important: When configuring a custom application for SCIM integration, the OAA payload structure (Application template) and SCIM configuration serve different purposes:

• The OAA Payload (push_application() or API push) defines local users, groups, permissions, and resources used for visibility and authorization modeling in Veza, and can be updated independently.

• The SCIM Configuration (configuration_json) for the custom provider defines how to connect to SCIM endpoints (including authentication, URL, and endpoint paths), and is used only for lifecycle management and access request operations.

Both must be consistent (describe and contain the same users and groups), but are configured separately.

Your application must expose SCIM 2.0 compliant endpoints with the following operations:

User Management:

• GET /Users - List and filter users

• GET /Users?filter=userName eq "{username}" - Query users by userName

• POST /Users - Create new users

Group Management:

• GET /Groups - List groups

• GET /Groups/{id} - Retrieve specific group by ID

• PATCH /Groups/{id} - Update group membership

Note: If the Users and Groups APIs are not at the standard /Users and /Groups paths, you can specify alternate endpoint paths in the configuration.

Your SCIM API must support one of the following authentication methods:

• Bearer Token: API token passed in Authorization: Bearer {token} header

• Basic HTTP Authentication: Username and password passed in Authorization: Basic {credentials} header

The authentication credentials must have both read and write permissions to the SCIM endpoints.

To synchronize custom attributes beyond the standard SCIM user schema:

• Expose a GET /Schemas endpoint that returns SCIM schema definitions

• Enable schema fetching in your configuration (see Configuration section)

External SCIM for Lifecycle Management is configured via the Veza REST API.

Create a Custom Provider that uses external SCIM endpoints specifically for lifecycle management:

Required Fields

Configuration JSON Parameters

The configuration_json field contains SCIM endpoint connection details used only for provisioning operations. It does not affect your OAA payload structure.

* One of scim_token or the username/password pair is required for authentication.

Example Configuration with Bearer Token:

Example Configuration with Basic Authentication:

Push the OAA Application Payload as normal. See the for details.

Veza creates entities in Access Graph based on the OAA payload, which can be targeted in lifecycle management operations:

• local_users in your Application template → Users to provision via SCIM

• local_groups in your Application template → Groups to manage via SCIM

Entity types are named according to the following pattern:

• User Entity Type: OAA.{application_type}.User

• Group Entity Type: OAA.{application_type}.Group

Where {application_type} is the value you specify in your OAA Application template when building the payload. For example, if the application is defined:

The resulting entity types are:

• OAA.CustomerPortal.User

• OAA.CustomerPortal.Group

When Veza provisions users via SCIM, transformers can map attributes from your policy source of identity to SCIM properties:

If the SCIM service exposes a /Schemas endpoint and you enable scim_extension_schemas: true, Veza can synchronize custom extension attributes beyond the standard SCIM user schema. Extension attributes are mapped using the schema URN as defined by your SCIM implementation.

The following SCIM operations are performed when Lifecycle Management actions execute:

Create a new user in the target application.

SCIM Operation:

The SCIM endpoint creates the user and returns the user object with an assigned id.

Updates an existing user's attributes (one-time or continuously).

SCIM Operations:

1. Query for existing user:

2. Update the user:

Remove access when a user leaves the organization or changes roles. The user account is deactivated, but data is preserved.

SCIM Operation:

Deprovision sets active=false, which disables login but preserves the user record.

Permanently remove a user account.

SCIM Operation:

Grant a user access via group membership.

SCIM Operations:

1. Retrieve group details:

2. Add user to group:

Revoke a user's access by removing group membership.

SCIM Operation:

Overview

This page covers the integrations that power Lifecycle Management workflows and can act as identity sources for LCM policies, and target applications that can be provisioned or deprovisioned.

Enabling provisioning on an integration also makes it available to other Veza products that use write-back capabilities, including Access Intelligence (Disable Accounts) and Access Requests. The integration tables below represent the validated, production-ready set for Lifecycle Management specifically.

Veza supports four implementation pathways:

1. Native Integrations: Direct, API-based provisioning, with out-of-the-box support for 25+ validated target applications (listed below).

2. SCIM 2.0 Protocol: Standards-based provisioning for any enterprise application that exposes a SCIM 2.0 interface.

3. OAA Write Framework: Veza's Open Authorization API (OAA) extends write-back to applications that Veza does not integrate with natively. This pathway is typically used for homegrown and custom applications.

4. Direct REST, XML, and SQL Actions: For an application that neither integrates natively nor exposes a SCIM interface, a dedicated Send REST Payload, Send XML Payload, or Send SQL Command action calls the target system directly. Use these actions to notify a platform when a joiner, mover, or leaver (JML) workflow completes, or to start work in that platform as a workflow step.

Combined, these approaches cover the enterprise application landscape reachable via Lifecycle Management target applications and actions: natively integrated systems, any SCIM-compliant application, homegrown and custom applications modeled through OAA, and any remaining system that exposes a reachable REST, XML or SOAP, or SQL interface.

The validated integrations listed below represent tested, production-ready configurations. For additional integration support, contact your Customer Success Manager.

Identity sources are authoritative systems that provide information about user identities. While Veza does not require write permissions to the identity source of truth, some of these integrations are also supported as provisioning targets. Integrations can also allow write-back of a user's newly created email address to the user's record in the source of identity as part of the initial provisioning workflow.

Veza supports leading HR systems, IDPs and directory services, ITSM platforms, payroll systems, custom applications, and flat files:

The following integrations are validated as provisioning targets for Lifecycle Management workflows. Enabling provisioning on an integration enables actions (create, sync, deprovision, manage relationships) that can be triggered from LCM policies and from other Veza products.

Validated Integrations

The following table lists the out-of-the-box, Veza-validated target application integrations.

Other Supported Integrations

For any Veza-supported application not listed above, contact your Customer Success Manager for more details on how to enable the specific Veza integration for use with provisioning as a target application for provisioning and de-provisioning.

Direct REST, XML, and SQL Actions

For an application that does not integrate with Veza natively and does not expose a SCIM interface, a workflow can call the target system directly:

• makes an HTTP request to an external API, webhook, or REST-based service.

• sends an XML or SOAP-over-HTTP body to a legacy endpoint.

• runs a SQL statement against MySQL, Microsoft SQL Server, Oracle, PostgreSQL, or SAP IQ (Sybase IQ).

Use these actions to notify a platform when a joiner, mover, or leaver workflow completes, to start work in that platform, or to coordinate provisioning across multiple downstream applications. Because each action targets an endpoint you supply, the three actions together extend provisioning support to systems that have no native or SCIM connector.

An Insight Point is required to enable provisioning operations and identity discovery for systems that Veza cannot access directly, such as an on-premises application server behind a firewall. The Insight Point is a lightweight connector that runs in your environment, enabling secure gathering and processing of authorization metadata for provisioning tasks.

A Veza Insight Point is typically deployed as a Docker container or VM OVA, running within your network for metadata discovery and provisioning job execution. This ensures secure communication between your environment and Veza.

For deployment instructions, refer to the .

You can configure extraction intervals for your integrations to ensure data is regularly updated for provisioning workflows.

1. Go to Veza Administration > System Settings

2. In the Integrations section, set the global Extraction Interval

3. To override the global setting for specific integrations, use the Active Overrides section

Available extraction intervals are:

• Auto (each integration's default, which is 1 hour for most of them)

• 1 Hour

• 6 Hours

• 12 Hours

One hour is the shortest extraction interval for most integrations. A 15-minute option appears in the Discovery Interval control, which is a separate setting and does not apply to extraction. See .

To manually trigger an extraction:

1. Go to Integrations > All Data Sources

2. Search for the desired data source

3. Select Actions > Start Extraction

Note: Custom application payloads are extracted after the payload is pushed to Veza using the Open Authorization API.

To enable provisioning for a specific integration:

1. Open the Integrations page (in the Featured section of the navigation sidebar), or Lifecycle Management > Integrations (in the Products section).

2. Search for the integration you want to enable and open its settings.

3. Check the Enable usage for Provisioning checkbox, then click Save Configuration.

After saving, the integration shows Enabled in the Lifecycle Management column on the Integrations overview.

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 sidebar on the right (not the Properties tab), click the magnifying glass icon next to the Provisioning Support value

Many identity source systems have API rate limits that can affect extraction timing. Avoid forcing repeated extractions within short time windows (typically 5 minutes) to prevent API errors that delay workflow execution.

For systems using custom or user-defined fields (UDFs), maintain clear documentation of:

• Field purpose and mapping

• Expected data formats and validation rules

• Which fields are used in workflow trigger conditions

This documentation ensures consistency when fields are added or modified.

Understand the data retention policies of your identity sources, particularly for terminated employees or contractors. Some systems retain terminated records for limited periods (e.g., 90 days), which affects leaver workflow design. Plan workflow timing to ensure LCM can process records before they're purged from the source system.

Changes to core identity fields can break LCM workflows. Coordinate with system administrators before modifying:

• Unique identifiers (employee ID, username)

• Employment status fields

• Date fields (hire date, termination date)

• Location or department identifiers

Communicate planned changes in advance and test in sandbox environments before applying to production identity sources.

For more information:

• Refer to individual integration documentation for detailed provisioning capabilities

• Consult the Veza documentation for troubleshooting and best practices

• Contact Veza support for assistance with enabling or configuring provisioning for your integrations