Custom Identity Mappings

Overview

Custom identity mappings define relationships between user identities and groups across the systems integrated with Veza. When your access federation does not produce these connections on its own, you can specify the attributes Veza compares to correlate identities between two systems, for example connecting an Okta user tom.shaw@veza.com to a SQL Server login DOMAIN\tshaw.

Use custom identity mappings to:

• Connect identity provider users, such as Okta users, to local accounts, such as Trino users

• Connect identity provider groups to groups in downstream systems, such as an Active Directory group to an Okta group, or an Entra ID group to a GitHub team

• Correlate identities on an attribute Veza does not compare automatically, such as an employee ID, an email alias, or a custom property

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

• Correlate identities in a to those in another integrated provider such as Okta

• Map identity provider users to local users in a , as an alternative to setting in the payload

• Define access-granting relationships for any user or group that shares a name, email address, or other property in Access Graph

• Identify local account ownership using consistent naming patterns

When you use more than one identity provider, a single person exists as a separate identity in each one, and Access Graph holds a distinct user entity for every provider. For example, the same employee can appear as an Okta user, an Active Directory user, and an Azure AD user. Veza assesses risk for each identity independently and records each risk on the identity that a risk query matches. Correlating a person's identities does not combine or transfer their risk scores, so covering every identity provider comes down to making sure a risk query evaluates each provider's users.

Built-in Veza risk queries are rooted at specific provider user types, such as Okta and Active Directory users. A query rooted at one provider's user type evaluates only that provider, so a provider that has no risk queries of its own, such as Azure AD, can be left without risk coverage.

To assess risk uniformly across every identity provider, author your risk queries against a user supertype instead of a single provider's user type. Every provider's user type derives from a shared user supertype, so one supertype query evaluates users from every identity provider and records risk on each. This reaches providers that have no built-in queries of their own, without maintaining a separate query for each provider. See for selecting an entity type or supertype as the query source, and for assigning risk levels.

Configure a mapping when any of these apply:

• The two systems have no automatic correlation between them. See for what Veza covers.

• The only value the two systems share is an attribute Veza does not compare automatically, such as an employee ID, a secondary email address, an email alias, or a custom property.

• The values are equivalent but not identical, and need a domain removed, punctuation ignored, or a naming convention applied.

• You are connecting a custom application or custom identity provider built with the

Before configuring identity mappings:

• Integrate both the source and destination systems with Veza, and confirm each has completed an extraction

• Verify you have permission to modify integration configurations

• Identify the attribute or pattern that correlates identities across the two systems

An OAA application appears in the destination list only after it has pushed data at least once, because Veza builds that list from the entity types present in Access Graph.

To enable custom mappings for an identity or cloud provider:

1. Go to the Integrations page.

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

3. Open the Mapping Configuration step.

4. Select Add Mapping Configuration.

Each mapping configuration covers one destination data source type per mapping mode. To correlate both identities and groups with the same destination, add two mappings, one in each mode. A mapping cannot target the source provider itself, such as one Okta domain to another, and Veza rejects a set of mappings that would form a loop between providers.

A property matcher names the property to compare on each side. Both dropdowns offer the same five options:

• Unique ID: the identity's unique identifier. Veza reads the identity_unique_id, identity_unique_ids, and idp_unique_id properties.

• Email: the identity's email address. Veza reads the email and emails properties.

The two sides do not have to use the same option. Mapping the Okta Property employee_id to a custom application's Custom Property employee_id is the supported way to correlate on employee ID, which Veza does not compare automatically.

Transformations adjust values on both sides before Veza compares them:

• Ignore Special: removes characters that are not letters or digits from the name portion of the value. A domain, if present, stays intact.

• Ignore Domain: removes the domain portion of the value. Veza recognizes both user@domain and DOMAIN\user forms.

Enable both to compare DOMAIN\j.smith with jsmith.

When more than one property matcher is defined, an OR and AND toggle appears in the upper-right corner of the property matchers section:

• OR, the default: a match on any property matcher correlates the identities. Use OR when identities may follow different conventions across systems.

• AND: all property matchers must match. Use AND for stricter correlation when you need high-confidence matches based on multiple attributes.

An OR configuration such as this matches any of john.smith, jsmith, or john.smith@company.com for a user named John Smith:

An AND configuration such as this correlates a user only when both attributes align, which reduces false positives where names or email domains are shared:

A Template property matcher compares transformed values instead of raw ones, which correlates identities that follow different naming conventions in each system. A template expression can reference any property on the entity and chain functions such as LOWER, REMOVE_DOMAIN, and SUB_STRING.

For the template syntax, the properties Veza provides, and every supported transformation function, see .

Identity matchers correlate two specific identities by name, for the accounts your property matchers cannot cover:

1. Select Add Identity Matcher.

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

3. In the rightmost dropdown, choose the corresponding identity in the destination data source.

Veza evaluates identity matchers only for destination identities that no property matcher resolved, so they act as exceptions rather than overrides. Identity matchers are available when editing an existing integration, after both sides have extracted, and are not available for OAA-based sources.

Saving a mapping does not create relationships on its own. Veza applies the configuration during the next extraction and parse of the source integration, and the relationships appear when that completes. To apply a mapping sooner, run an extraction on the source integration.

Query paths become available as soon as you save, so a query can reference the relationship before any relationships exist.

• Comparison ignores case on both sides. Jane.Doe@company.com and jane.doe@company.com are equivalent.

• Empty values do not match, including when a transformation reduces a value to an empty string.

• Every match creates a relationship. If a destination identity matches several source identities, Veza creates a relationship for each, so keep the compared values unique when you need a single correlation.

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.

1. Active Directory to SQL Server:

   • Source: Active Directory user email admin@yourdomain.com

   • Destination: SQL login YOURDOMAIN\admin

1. Entra ID to GitHub:

   • Source: Entra ID group Engineering-Team

   • Destination: GitHub team Engineering Team

AWS integrations support mapping IAM roles directly to local users in downstream applications. This is useful when IAM roles represent service accounts or federated identities that correspond to application-level users.

1. AWS IAM role to custom application user:

   • Source: AWS IAM role DataAnalyticsRole

   • Destination: custom application user analytics-service

To configure role to user mapping:

1. Edit your AWS integration and open Mapping Configuration.

2. Select Roles to Users as the mapping mode.

3. Choose a destination data source type, such as Custom Application, Snowflake, or SQL Server.

4. Add property matchers to define how role attributes map to user attributes.

Configure a mapping on the source integration. These integrations can hold a mapping configuration:

• Active Directory, Entra ID (Azure AD), Google Workspace, Okta, OneLogin, and PingOne

• AWS, which also supports the Roles to Users mapping mode

• Workday

• Sources built with OAA: custom identity providers, secret stores, and HRIS sources, including CSV HRIS uploads, Database HRIS, LDAP, and HRIS connectors such as HiBob, Personio, and Oracle HCM

Available destinations:

• Identity providers: Active Directory, Entra ID (Azure AD), Google Workspace, Okta, OneLogin, PingOne, AWS Identity Center, Oracle Cloud IAM domains, CyberArk Identity

• Databases and warehouses: Snowflake, Trino, SQL Server and Azure SQL (server logins and per-database users), Oracle Database, AWS Redshift, AWS RDS for MySQL, AWS RDS for PostgreSQL

• Cloud and platform: AWS IAM, Databricks workspaces and AWS Databricks accounts, HashiCorp Vault namespaces, Privacera

To map identities to many destinations from one configuration, contact your Veza support representative to enable that capability. When enabled, Destination Data Source Types accepts more than one selection.

• for the attributes Veza compares without configuration

• for template expressions and transformation functions

• for setting identity values in an OAA payload