Use the Veza Integrations section to add and manage all the connections between Veza and your Identity Providers, Cloud Providers, SaaS Applications, Data Lakes, and other systems.

To add an integration:

1. Choose Integrations on the Veza navigation bar.

3. Click the icon for the integration you want to add.

4. Configure the integration by completing the required fields.

5. Click Create Integration to save the configuration and queue the first synchronization.

The requirements for each integration depend on the system you are connecting to. See Veza Integrations for links to detailed integration guides.

Integrations Management

For example, you could create a team named "AWS Production" and invite key engineering team members with the "Integrations Manager" role. This will enable these users to manage and connect all AWS accounts within Veza, while preventing access to data from any integrations not explicitly assigned to their team.

Assigning Integrations Managers

As a Veza admin, you can create new teams and manage existing ones to enable dedicated managers for integrations. Note that Users with the "Integrations Manager" role must also have the "Viewer" role, or the user will not be able to log in.

To assign a team member to manage integrations within an existing team:

1. In Veza, go to Administration > Team Management.

2. Select the "Add Users" option in the corresponding team's row. You can also create and remove teams on this page.

3. Choose the user and assign them the "Integrations Manager" role.

To add or remove the "Integrations Manager" role for existing team members:

1. Go to Administration > User Management.

2. Locate the user you want to manage, and click "Change Roles"

3. Use the role selector to adjust their roles within existing teams, or add them to a new team.

Integrations Detail Pages

On the Integrations page, you can filter the list of all Integrations by Name, Provider Type, and Status. Click View Dashboard to open the Access Intelligence Analytics dashboard for that integration.

Selecting an existing integration from the Integrations page opens an overview page providing information. You can switch between tabs to get more details about the configuration:

• Data Sources: Displays all discovered data sources in the integrated system

• Workers: Shows all of the Worker agents spawned by Veza to do discovery based on the architecture of the integrated system. Some integrations, such as cloud providers, will create several discoverers. Other integrations such as simple RBAC SaaS Applications or Data Sources connected with Veza’s Open Authorization API (OAA) will have no Workers.

• Properties: Displays properties and configuration settings for the chosen integration.

• Events: Displays log messages and events associated with the chosen integration.

Veza Actions Page

The Veza Actions page is where you configure the downstream integrations and webhooks that send notifications and take action on downstream systems such as ticketing platforms.

Veza Actions can be filtered by Name and Type. Use this tab to edit, test, or delete configured actions.

All Data Sources Page

The All Data Sources page lists all of the data sources that Veza is receiving authorization metadata from, based on the integrations configured in your tenant.

Data Sources can be filtered based on Name and Status.

Active Jobs Page

The Active Jobs page provides real-time intelligence on the Data Sources that are currently in progress, or have errors. You can use this page to review data sources that need attention.

Data sources on the Active Jobs page can be filtered by Name.

Insight Points

For security reasons, you must re-enter the credentials and secrets when changing the Insight Point associated with an integration.

Enrichment

The Integrations > Enrichment page allows you to create and manage enrichment rules. These rules automatically categorize entities in your environment based on custom criteria. You can create rules to identify:

• Non-Human Identities (NHI)

• Privileged Access roles

• Critical Resources

Enrichment rules use saved queries to identify entities and apply special attributes, which can then be used to create queries, reports, and access reviews. This automation helps streamline security operations and enhance visibility into your authorization landscape.

To create a new enrichment rule, click Create Rule and specify the rule type, integration, entity type, and saved query to use. You can also view, edit, enable/disable, and delete existing rules from this page.

Audit Log Extraction

Administrators can use the integration actions menu to enable or disable audit log extraction for supported integrations. If enabled and configured for a cloud or data provider, Veza will periodically collect audit logs instead of conducting full extractions. When there are changes, the corresponding data source is marked "out of date" and queued for a full update.

Integration Extraction and Discovery Intervals

Veza periodically connects to integrated systems to discover new data sources and update the Authorization Graph with the latest metadata and relationships. You can customize how often these processes occur to optimize performance, reduce costs, and manage resource usage.

Key points about extraction and discovery intervals:

• Discovery intervals (15 minutes to 30 days) determine how often Veza checks for new data sources.

• Extraction intervals (1 hour to 30 days) set the frequency of authorization metadata updates.

• Intervals can be set globally or customized for individual providers.

• Adjusting these intervals can help balance update frequency with system performance and costs.

Veza periodically connects to integrated systems to maintain an up-to-date graph of authorization and relationships between entities in your environment. This process involves two main activities: discovering new data sources and extracting authorization metadata.

By customizing extraction intervals globally or per-integration, you can achieve both:

• Cost Reduction: Longer extraction intervals can reduce compute costs for systems like Snowflake, where each extraction may incur API charges.

• Performance Improvement: Increasing intervals for integrations with large data sources can prevent bottlenecks and reduce delays in updating other integrations and services.

All integrations have a default auto setting which can vary depending on the integration type. For most integrations it is 1h. Some integrations are adjusted to reduce cost and potential bottlenecks, such as for Sharepoint Sites (24h), Snowflake (6h), and Box (24h).

The auto setting allows Veza to manage extraction timing based on system load and integration type. When you override with a manual setting, Veza will schedule extraction precisely at that interval regardless of system conditions.

An administrator can change the default value for each integration, or set global extraction and discovery intervals.

Discovery Interval

• Determines how often Veza checks for newly added data sources in your integrated systems.

• The discovery interval can be set between 15 minutes and 30 days.

Extraction Interval

• Determines how often Veza collects authorization metadata to update entities in the Authorization Graph.

• Extraction intervals can be set between 1 hour and 30 days.

• Gathers supported entities and their attributes, which can take some time for large data sources.

• More frequent extractions ensure entity relationships and attribute updates are current but may impact system performance.

How to Customize Intervals

1. Open the Administration page on the main Veza navigation bar.

2. Go to the System Settings tab.

3. Scroll down to the Integrations section.

4. Use the dropdown menus to set global values for discovery and extraction intervals.

   • Discovery Interval: How frequently to discover datasource instances.

   • Extraction Interval: How frequently to extract datasources.

5. To customize intervals for specific providers:

   • Use the Search field to filter for a specific integration.

   • Set custom values for individual providers as needed (from auto to 1-30 days).

After updating an override, it will be listed beneath the global values, along with any other active overrides. Changes take effect immediately, with the next scheduled extraction/discovery following the new interval settings.

Considerations

Tuning extraction and discovery intervals can optimize performance while maintaining an up-to-date view of your authorization landscape.

• Balance frequency of updates with system performance and cost.

• Monitor the impact of your changes to ensure they meet your organization's needs.

• Remember that less frequent updates may result in slightly outdated data between extractions.

When connecting to a configured identity or data provider, Veza will attempt to discover all supported resources by default. There are two methods to limit the services and resources discovered:

• Toggle discovery of select services (skipping services such AWS KMS or Azure SQL entirely)

• Set allow and deny lists to limit data sources by name (only parsing individual resources)

You can enable these preferences when adding a new provider, or change them for an existing integration by finding the provider in the Configuration menu and clicking the "Edit" button.

To toggle services discovered, choose Select services to enable in the provider configuration. When you save your changes, only the selected services will be scanned and added to the data catalog.

Allow or deny data sources

You can set allow and deny lists to limit extraction by resource name (including wildcards). Allow/deny lists are available for most data sources, including Google Cloud projects/domains, AWS Redshift/RDS databases, S3 buckets, and Snowflake databases.

When an allow list is saved, only resources with a matching name are parsed and added to the Identity Data Entities catalog. If a deny list is configured, any data sources with a matching name will be ignored during discovery.

The following rules apply:

• If no values are provided, all data sources are extracted

• If a resource name matches the allow list, it will be extracted

• If a resource name matches the deny list, it will be ignored

• Resources are only extracted if allowed and not denied (in the case that both allow and deny lists are configured)

Naming conventions

The value to use as the resource name depends on the provider. See the table below for more information about the format:

Azure settings

When modifying an Azure tenant configuration, several additional options are available:

Overview

Enrichment rules allow you to automatically identify and categorize important entities in your environment, such as privileged roles, critical resources, and non-human identities. After configuring an enrichment rule, matching entities are updated with special attributes. Using these attributes to define filters and conditions enables rules, access reviews, and other capabilities for these special entities.

• An attribute (e.g., a naming convention or another property that identifies non-human service accounts)

• Permissions granted by a role

• Other distinguishing relationship between entities.

Enrichment Rule Types

Veza currently supports three types of enrichment rules:

• Non-Human Identities (NHI): Automatically label users with the identity type attribute by setting the value to HUMAN or NONHUMAN.

• Privileged Access: Roles that meet the query condition will have the is privileged attribute set to TRUE.

• Critical Resources: Resources in the query results will have the criticality level attribute set to LOW, MEDIUM, HIGH, or CRITICAL.

When extracting metadata from an integration, Veza will check for matching enrichment rules and update entities that meet the conditions specified by the saved query. For example, an enrichment rule could label roles that grant access to specific permissions or resources as "privileged," mark identities as non-human based on a naming convention, or set a criticality level for resources based on existing tags or attributes.

Create an Enrichment Rule

Administrators can use the Integrations > Enrichment page to manage and create rules. To create a rule, you must specify:

• The enrichment rule type.

• The integrations, data sources, and entity type the rule applies to.

• Rule options, such as the criticality level for critical resources.

To define an enrichment rule:

1. Navigate to the Enrichment Page:

   • Go to Integrations > Enrichment.

   • Click Add Enrichment Rule.

2. Name the Rule:

   • Enter an identifiable name in the Rule Name field.

3. Select the Enrichment Rule Type:

   • Choose one of the following options:

     • Non-Human Identities (NHI): For matching users, set the identity type attribute value (HUMAN or NONHUMAN).

     • Privileged Access: For matching roles, set the is privileged attribute to TRUE.

     • Critical Resources: For matching resources, set the criticality level attribute (LOW, MEDIUM, HIGH, or CRITICAL).

4. Choose Integrations:

   • Use the Integrations dropdown to select the specific integrations the rule will apply to.

5. Select Entity Type:

   • Choose a supported Entity Type (e.g., users, roles, resources) from those data sources.

6. Pick a Saved Query:

   • Select a saved query that identifies the entities to enrich.

7. Save the Rule:

   • Click Save to apply the changes.

Veza will apply the enrichment rules the next time data sources are extracted. You can trigger this manually by clicking Start Extraction on the Integrations > All Data Sources page.

Manage Enrichment Rules

Use the Integrations > Enrichment page to view all rules and edit or delete individual rules:

1. Access the Enrichment Page:

   • Go to Integrations > Enrichment.

2. View Rules by Type:

   • Choose a tab to view rules by type:

     • Non-Human Identities (NHI)

     • Privileged Access

     • Critical Resources

3. Edit or Delete Rules:

   • Click Edit to update a rule or Delete to remove it.

4. Enable / Disable Rules:

   • Toggle the switch in the Enabled column to activate or deactivate a rule.

   • Disabling a rule removes its enrichment metadata from existing entities upon the next data source extraction.

This document provides instructions for setting up and running Veza Python scripts on Linux, Windows, and Mac operating systems. Users seeking to automate Veza Python scripts on different platforms can refer to the sections below to learn about:

• Verifying Python Installations

• Installing Required Packages

• Setting Environment Variables

• Executing Scripts

• Scheduling Periodic Script Runs

• Setting Temporary and Persistent Environment Variables

These instructions are especially intended to help run and schedule Open Authorization API connectors provided as Python packages.

Linux

Setup

Verify Python3 Installation

Many current Linux distributions typically have python3 installed by default.

To verify that python3 is installed on your system, run the following command:

which python3
which pip3

If the outputs are filesystem paths (ex: /usr/bin/python3), the applications are installed.

Installing Required Packages

Veza Python scripts may rely on external dependencies; if this is the case, the script package will include a requirements.txt file.

To ensure that the dependencies are installed, run the following command from the directory in which the requirements.txt file is located:

pip3 install -r requirements.txt

Setting Environment Variables

Veza Python scripts often require some variable input at run time (ex: API key, service URL).

Non-secret data can be passed to the script as arguments or set as environment variables, but sensitive data must be set as an environment variable.

See the README.md packaged with a script for a description of required input data.

Temporary Environment Variables

Environment variables can be set temporarily from the Linux shell; these settings will last until the shell process in which they are set is terminated.

To temporarily set an environment variable from the Linux shell, run the following command:

export <variable_name>="<value>"

An example setting VEZA_URL to the FQDN of a Veza instance:

export VEZA_URL="https://example.vezacloud.com"

To verify currently set environment variables and their values, run the env command from the terminal.

To remove a currently set environment variable, run the following command:

unset <variable_name>

Unsetting the previously established VEZA_URL example:

unset VEZA_URL

Persistent Environment Variables

Environment variables can be set persistently in several ways, each with their own scope.

In each case, edit the relevant file and add the following line to set the new variable:

export <variable_name>="<value>"

• To set a persistent environment variable for only the currently logged-on user, edit ~/.bashrc and add the export to the end of the file.

• To set a variable for all login shell sessions, edit /etc/profile and add the export to the end of the file.

• To set a system-wide variable, edit /etc/environment and add the export to the end of the file.

Current shell sessions will not reflect the file update immediately - to make use of the newly set variable, source the file first:

source ~/.bashrc

Execution

To run the Veza Python script, chmod the file to make it executable, then execute it:

chmod +x <script_name>.py
./<script_name>.py

To pass additional parameters not set as environment variables when executing the script:

./<script_name>.py --<parmeter1_name> <parameter1_value> --<flag_parmeter>

An example of setting a parameter with a value along with a flag parameter:

./veza_script.py --veza_url https://example.vezacloud.com --debug

Scheduling

Periodic executions of scripts can be configured to run via cron or via systemd, depending on your environment.

Cron

Scheduling via cron requires a line to be added to the crontab.

Note: cron executes commands without a login shell; environment variables set in ~/.bashrc or /etc/profile will not be loaded.

To edit the crontab, run crontab -e, then add the following:

VEZA_URL="https://example.vezacloud.com"
VEZA_API_KEY="k124c021...fc1d281"
0 * * * * /usr/bin/python3 /path/to/<veza_script.py>

Some distributions do not honor environment variables set in the crontab file; in those cases, they can be set inline:

0 * * * * root env VEZA_URL="https://example.vezacloud.com" VEZA_API_KEY="k124c021...fc1d281" /usr/bin/python3 /path/to/<veza_script.py>

Systemd

Scheduling via systemd requires a timer unit file and a corresponding service unit file.

Begin by creating the timer unit file (vim /etc/system/systemd/<veza_script>.timer):

[Unit]
Description=Execute Veza Python Script Every Hour

[Timer]
OnCalendar=daily

Unit=<veza_script>.service

[Install]
WantedBy=timers.target

Then create the service file (vim /etc/system/systemd/<veza_script>.service):

[Unit]
Description=Veza Python Script Service

[Service]
# Environment variables can be defined here
Environment=VEZA_URL="https://example.vezacloud.com"
Environment=VEZA_API_KEY="k124c021...fc1d281"
Type=simple
ExecStart=/usr/bin/python3 /path/to/<veza_script.py>

[Install]
WantedBy=multi-user.target

Run the following commands to reload service definitions and enable the new service:

systemctl daemon-reload
systemctl enable <veza_script>.service
systemctl start <veza_script>.service

Windows

Setup

Verify Python Installation

Note: During installation, ensure the Add python.exe to PATH checkbox is selected.

To ensure that python and pip are properly installed and added to the PATH, open a Command Prompt and run:

where python
where pip

Both commands will return paths on the filesystem if the executables are located.

Installing Required Packages

Veza Python scripts may rely on external dependencies; if this is the case, the script package will include a requirements.txt file.

To ensure that the dependencies are installed, run the following command from the directory in which the requirements.txt file is located:

pip install -r requirements.txt

Setting Environment Variables

Temporary Environment Variables

Command Prompt

To set an environment variable for an existing Command Prompt session, run the following:

set <variable_name>=<value>

An example setting VEZA_URL to the FQDN of a Veza instance:

set VEZA_URL="https://example.vezacloud.com"

To remove the previously set VEZA_URL example:

set VEZA_URL=

PowerShell

To set an environment variable for an existing PowerShell session, run the following:

$env:<variable_name> = '<value'

An example setting VEZA_URL to the FQDN of a Veza instance:

$env:VEZA_URL = 'https://example.vezacloud.com'

To remove the previously set VEZA_URL example:

Remove-Item env:\VEZA_URL

Persistent Environment Variables

To set environment variables on a Windows system, follow these steps:

• On the taskbar, right-click the Windows icon and click System

• In the Settings window, locate and click Advanced system settings

• In the System Properties window that appears, click the Environment Variables button near the bottom.

• In the Environment Variables window that appears, choose the scope for the new variable. User-specific variables are listed at the top of the window with system-wide variables below.

• Click the New button underneath the appropriate scope.

• Complete the New System Variable dialog that appears, providing a Variable name and Variable value, then click OK Note: no quotes are required for complex variable values when set via this method

Current Command Prompt and PowerShell sessions will not update immediately - to make use of the newly set variable, start a new Command Prompt or PowerShell session.

Execution

To run the Veza Python script, open a Command Prompt window and execute the following:

python <script_name>.py

To pass additional parameters not set as environment variables when executing the script:

./<script_name>.py --<parmeter1_name> <parameter1_value> --<flag_parmeter>

An example of setting a parameter with a value along with a flag parameter:

./veza_script.py --veza_url https://example.vezacloud.com --debug

Scheduling

Periodic executions of scripts can be configured via the Task Scheduler interface on Windows.

Note: ensure that any required environment variables have been stored as system-wide variables before scheduling a task that utilizes them. Also stop the Taskeng.exe process to force Task Scheduler to reload environment variables.

• In the search bar, type Task Scheduler, then click on the search result to open the interface.

• In the Actions pane on the right side of the window, click Create Basic Task

• In the Create Basic Task Wizard, provide the following:

  • Name: A name for the scheduled task

  • Description: An optional longer description of what the task does

  • Trigger: Select a time-based trigger (Daily)

  • Daily time settings for task triggering

  • Program/script: Enter or browse to the installation location of the python executable

    • Add arguments: <script_name>.py --<parameter1_name> <parameter1_value>

    • Start in: c:\path\to\script\

Mac

Setup

Verify Python3 Installation

To install python3 on MacOS, ensure that Homebrew is installed and run the following command:

brew install python

To verify that python3 is installed on your system, run the following command:

which python3
which pip3

If the outputs are filesystem paths (ex: /usr/local/bin/python3), the applications are installed.

Installing Required Packages

Veza Python scripts may rely on external dependencies; if this is the case, the script package will include a requirements.txt file.

To ensure that the dependencies are installed, run the following command from the directory in which the requirements.txt file is located:

pip3 install -r requirements.txt

Setting Environment Variables

Veza Python scripts often require some variable input at run time (ex: API key, service URL).

Non-secret data can be passed to the script as arguments or set as environment variables, but sensitive data must be set as an environment variable.

See the README.md packaged with a script for a description of required input data.

Temporary Environment Variables

Environment variables can be set temporarily from the Linux shell; these settings will last until the shell process in which they are set is terminated.

To temporarily set an environment variable from the Linux shell, run the following command:

export <variable_name>="<value>"

An example setting VEZA_URL to the FQDN of a Veza instance:

export VEZA_URL="https://example.vezacloud.com"

To verify currently set environment variables and their values, run the env command from the terminal.

To remove a currently set environment variable, run the following command:

unset <variable_name>

Unsetting the previously established VEZA_URL example:

unset VEZA_URL

Persistent Environment Variables

Environment variables can be set persistently in several ways, each with their own scope.

In each case, edit the relevant file and add the following line to set the new variable:

export <variable_name>="<value>"

• To set a persistent environment variable for only the currently logged-on user, edit ~/.zshrc and add the export to the end of the file.

• To set a variable for all login shell sessions, edit /etc/profile and add the export to the end of the file.

Current shell sessions will not reflect the file update immediately - to make use of the newly set variable, source the file first:

source ~/.zshrc

Execution

To run the Veza Python script, chmod the file to make it executable, then execute it:

chmod +x <script_name>.py
./<script_name>.py

To pass additional parameters not set as environment variables when executing the script:

./<script_name>.py --<parmeter1_name> <parameter1_value> --<flag_parmeter>

An example of setting a parameter with a value along with a flag parameter:

./veza_script.py --veza_url https://example.vezacloud.com --debug

Scheduling

Cron

Scheduling via cron requires a line to be added to the crontab.

Note: cron executes commands without a login shell; environment variables set outside of the crontab will not be loaded.

To edit the crontab, run crontab -e, then add the following:

VEZA_URL="https://example.vezacloud.com"
VEZA_API_KEY="k124c021...fc1d281"
0 * * * * /usr/bin/python3 /path/to/<veza_script.py>

Core Integration Concepts

How do Veza integrations connect?

Veza connects to metadata sources (such as Identity Providers, Cloud Providers, SaaS Applications, and Data Lakes) through integrations managed on the Integrations page. Each integration periodically synchronizes to discover new data sources and extract current authorization metadata.

Veza integrations connect via read-only APIs to gather the necessary metadata information to create that integration’s access graph. Veza leverages the best-practice connection methodologies for each connector we build. Veza also generally supports additional connection methods, when another method defined by the target is the preferred method for the customer.

What metadata elements does Veza gather?

• Identity Metadata: User attributes and entitlements, including role assignments and group memberships.

• Employee Attributes: Unique identifiers (e.g., Employee Number, Unique ID), employment details (e.g., job title, employment status), and organizational structures (e.g., department, cost center).

• Application Metadata: Local users, groups, roles, permissions, and metadata related to resources and data objects that identities can access.

• Refer to individual integration guides for detailed information on supported entities and attributes.

How do integrations connect to data sources that restrict connectivity from outside a corporate network?

Deploying an Insight Point enables secure discovery of data sources that prohibit external connections from outside your corporate network. Typically deployed as a Docker container, Kubernetes service, or VM OVA, the Insight Point runs within your network to query internal-only data sources for authorization metadata and push that information to the Veza graph.

Insight Point Architecture

What is an Insight Point?

An Insight Point is a lightweight, static binary designed for secure metadata extraction within customer networks. It is packaged in various formats such as Docker container and OVA image, enabling integration of internal resources to Veza without direct/external exposure. The Insight Point performs local metadata collection and securely transmits the data to the customer’s Veza instance.

How does the Insight Point work?

Insight Points operate on a pull-based architecture:

• The Insight Point will securely connect to the customer’s configured Veza instance to retrieve extraction tasks.

• The Insight Point will take the response and perform the requested extraction work locally.

• After extraction, the Insight Point transmits the data back to the configured Veza instance.

Is there any external connectivity to the Insight Point?

No. All communication is strictly unidirectional with all connections initiated from the Insight Point. Veza cannot initiate inbound connections to the Insight Point.

Can the Insight Point work with firewalls and network proxies?

Yes. Veza’s Insight Point supports working through corporate firewall configurations, network proxy requirements, and standard enterprise network security controls.

Integration Management and Performance

Can administrators schedule when extraction happens (e.g. during off-peak hours)?

Veza can schedule best-effort custom extraction intervals for different integrations. Each integration has a default extraction interval. Most integrations default to hourly extractions.

Administrators can customize this interval for each integration (1 hour to 30 days) on the System Settings page to optimize cost, performance, and data freshness. Some integrations, such as SharePoint and Snowflake, support activity-based extraction, enabling updates only when changes are detected.

How does Veza handle performance impact on P0 systems (databases, SaaS apps, etc.)

Veza minimizes impact on business-critical systems with rate-limited API calls, optimized queries, and configurable extraction intervals. For supported integrations, administrators can enable activity-based extractions that only trigger when changes are detected, and set limits on the specific services, entities, and attributes gathered by Veza.

What happens when extractions fail or are interrupted?

Each integration handles extraction errors based on application-specific best practices, using automatic retry logic for recoverable issues. Non-recoverable errors (like missing permissions or service unavailability) fail the extraction and trigger a retry at the next scheduled interval. Administrators can monitor all extraction statuses and errors through the integration Details view and the Events page. Veza also supports exporting these events to external systems.

What happens to long-running or incomplete extractions?

Unfinished jobs are eventually interrupted and retried at the next extraction interval to prevent pipeline delays. Large extractions can take some time to complete, and are allowed to run for extended periods.

End-to-End Security

How does Veza ensure the security of integration data?

Veza protects integration data with multiple security layers. See the Security FAQ for detailed information about Veza's security and encryption practices.

• All communication uses TLS 1.2+ and AES-256 encryption.

• Integration secrets (such as OAuth credentials and API keys) are securely stored, with the option to manage using external vaults.

• Access to integration secrets is strictly limited to authorized Veza extraction services.

Platform-specific Integrations

How does Veza integrate to Microsoft Entra ID?

To integrate with Microsoft Entra ID, Veza connects through an Azure App Registration with read-only permissions to the Microsoft Graph API. It retrieves metadata about:

• Entra ID roles and role assignments

• Groups and group memberships

• Users and their attributes

• Service principals and their assigned roles

How does Veza integrate with Data Lakes (Snowflake)?

The Veza integration for Snowflake data lake discovery uses a local user configured with a role that grants access to metadata on:

• Users and their attributes

• Roles and role hierarchies

• Resources (databases, schemas, tables, and views)

• Permissions and access control policies

How does Veza integrate with SaaS apps (Salesforce)?

To integrate with Salesforce (SFDC), Veza connects via a Salesforce Connected App configured with API permissions to retrieve:

• User profiles and permissions

• Groups and their memberships

• Permission sets and assignments

• Data objects and access controls

• Sharing rules and account shares

Overview

Custom Identity Mappings allow you to define relationships between user identities and groups across different systems integrated with Veza. When your organization's access federation doesn't automatically create these connections in Veza, you can specify patterns to map users between systems (for example, connecting an Okta user tom.shaw@veza.com to a SQL Server login DOMAIN\tshaw).

Use custom identity mappings to:

• Connect IdP users (such as Okta users) to local accounts (such as Trino users)

• Connect IdP groups to groups in downstream systems (such as Active Directory Group to Okta Group, or Azure AD Group to GitHub Team)

• Define custom mapping rules for each integration, or use one mapping rule to link IdP identities or groups across multiple connected systems

• Define access-granting relationships for any user or group with the same name, email, or another property in the Veza graph database

• Identify local account ownership using consistent naming patterns

Examples

You can configure mappings for one or more target data sources based on entity attributes or use templates to correlate identities and groups across multiple destination data sources.

User Identity Mapping

1. Active Directory to SQL Server:

   • Source: AD User email admin@yourdomain.com

   • Destination: SQL Login YOURDOMAIN\admin

   • Configuration: Map email to unique ID, enable "ignore domain"

2. Okta to Custom Application:

   • Source: Okta user email jane.doe@company.com

   • Destination: App username jdoe

   • Configuration: Map email to custom property username

Group Identity Mapping

1. Azure AD to GitHub:

   • Source: Azure AD Group Engineering-Team

   • Destination: GitHub Team Engineering Team

   • Configuration: Map name to name, enable "ignore special characters"

2. Okta to Snowflake:

   • Source: Okta Group DataAnalysts

   • Destination: Snowflake Role DATA_ANALYSTS

   • Configuration: Map name to name, apply "UPPER" transformation

3. Multiple Resource Mapping:

   • Source: Active Directory Security Group Finance-Staff

   • Destinations:

     • Salesforce Group Finance Users

     • AWS IAM Group finance-users

     • Box Group Finance Department

   • Configuration: Single mapping configuration applying to multiple destination systems

Prerequisites

Before configuring identity mappings:

• Ensure both the source and destination systems are successfully integrated with Veza

• Verify you have the necessary permissions to modify integration configurations

• Identify the common attributes or patterns used to correlate identities across your systems

Enabling Identity Correlation

To enable custom mappings for an Identity or Cloud Provider:

1. Navigate to the Integrations page

2. Select a cloud or identity provider from the list and click Edit

3. Scroll down to the Mapping Configuration tab

4. Click Add Mapping Configuration

   1. Enable Use Email By Default to automatically map users based on email attributes

   2. For Mapping Mode, choose Users to create a rule for correlating individual identities. Choose Groups to connect source and destination groups.

   3. For Destination Data Source Type, select the target system for identity mapping

      Identity Mapping for Multiple Resources: If you need to configure identity mappings to many target systems, Veza supports using a single identity mapping configuration to connect users in the IdP to any number of destinations. Contact your Veza support representative to enable this feature. When enabled, you can select more than one Destination Data Source Types from the dropdown menu.

   4. Click Add Property Matcher to create a mapping rule

   5. Under Property Matchers, choose the source system attribute:

      • Email or Unique ID for native integrations like Okta

      • Template for pattern-based matching (see Template Transformations below)
   6. Select the matching destination system property (Email, Unique ID, Template, or Custom)

   7. Configure optional transformations:

      • Ignore Special Characters: Match identities that differ only by special characters (_, -, .)

      • Ignore Domain: Match identities after removing domain portions

5. Add additional property matchers as needed (combined with OR logic)

6. Click Save Configuration

Identity Matchers

Add identity matchers to correlate specific identities that don't meet the conditions of another property matcher:

1. Click Add Identity Matcher to add a mapping rule

2. In the leftmost dropdown, choose a specific identity from the source integration

3. Use the rightmost dropdown to pick the corresponding identity in the destination data source

Template Transformations

Template transformations enable complex identity mapping patterns using property values and transformation functions. This feature is particularly useful when:

• Source and destination systems use different naming conventions

• You need to normalize user identifiers across systems

• You want to define global mapping rules that work across multiple applications

Template Syntax

Templates use property placeholders with optional transformation functions:

{PropertyName | FUNCTION1 | FUNCTION2,...}

For example, to transform a user's name from "JOHN DOE" to "jdoe":

{FirstInitial | LOWER}{LastName | LOWER}

Supported Properties

Templates support the user properties:

• FirstName: User's first name

• LastName: User's last name

• FirstInitial: First character of first name (equivalent to {FirstName | SUB_STRING,0,1})

• LastInitial: First character of last name (equivalent to {LastName | SUB_STRING,0,1})

Transformation Functions

Templates can use transformation functions to map identities based on a partial match or a variation of the source attribute.

SUB_STRING

Extracts a portion of text.

• Parameters:

  • start_index: Starting position (0-based)

  • length: Number of characters to extract

• Example: {FirstName | SUB_STRING,0,3} for "John" returns "Joh"

UPPER

Converts all characters to uppercase.

• Example: {FirstName | UPPER} for "John" returns "JOHN"

LOWER

Converts all characters to lowercase.

• Example: {FirstName | LOWER} for "John" returns "john"

TRIM

Removes leading and trailing whitespace.

• Example: {FirstName | TRIM} for " John " returns "John"

Function Composition

Multiple functions can be chained together, applied left to right:

{FirstName | TRIM | SUB_STRING,0,1 | UPPER}.{LastName | LOWER}

For a user "John Smith", this produces: "J.smith"

Common Template Patterns

Here are some frequently used template patterns:

1. First initial + last name:

   Copy

   {FirstInitial}{LastName}

   Example: "John Smith" → "jsmith"

2. First name + last initial:

   Copy

   {FirstName}.{LastInitial}

   Example: "John Smith" → "john.s"

Using OR Logic with Templates

Multiple property matchers can be combined using OR logic. The builder indicates these combinations with "OR" separators. For example:

Template: {FirstName}.{LastName} OR
Template: {FirstInitial}{LastName} OR
Property: email

This configuration would match any of these patterns for a user "John Smith":

• john.smith

• jsmith

• john.smith@company.com

When using templates with multiple property matchers, a match on any single pattern is sufficient to create the identity mapping.

Identity Mapping Use Cases

Common combinations for identity mapping include: