Custom Identity Mappings

Specifying cross-service user relationships during IdP configuration

Overview

Depending on how your organization federates access to systems, Veza may be unable to discover all the connections between Authorization Graph entities, such as Active Directory identities and local SQL server users.

When configuring an identity provider, you can specify patterns to map users within that domain to other entities in the Veza graph database (for example, Okta user [e-mail] custom IdP user [e-mail]).

Use custom identity mappings to:

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

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

• Map IdP users to local users in a custom application (as an alternative to using ids)

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

• Associate users in your identity provider with any application where Veza does not natively support cross-service connections.

Enabling Identity Correlation

To enable custom mappings for an Identity or Cloud Provider, edit the integration configuration and specify the attributes used to correlate identities:

1. Go to the Integrations page and pick a cloud or identity provider from the list of integrations. Click Edit.

2. On the Edit Integration screen, open Mapping Configuration tab.

3. Click Add Mapping Configurations. This option will only appear for supported integrations.

   1. Enable Use Email By Default to enable automatic mapping based on user email attributes.

   2. For Destination Data Source Type, choose another integrated system to map identities.

   3. Under Property Matchers, choose Email, Unique ID, or Custom from the dropdown. These refer to attributes in the source system.

   4. For native integrations such as Okta, choose Name or Unique ID.

   5. For integrations based on an OAA template (Custom Application or Custom Identity Provider), choose Custom and enter the custom property from template, e.g. idp_id.

   6. Choose the property in the destination system that should match property in the source system. This can be Email, Unique ID, or a Custom property for an OAA-based integration.

   7. Choose optional transformations:

      • Ignore Special Characters: identities must be identical aside from any special chars ( _, -, .), for example, tom.shaw = tom_shaw.

      • Ignore Domain: identities must be identical after omitting the domain (anything following an @): tom.shaw == [e-mail].

      • For example, mapping Active Directory User email to SQL Server Login unique ID, and choosing the ignore domain option, Veza will match [e-mail] to YOURDOMAIN\admin

4. Identity providers can have more than one mapping to other Data Sources. You should create a configuration for any systems that users from this integration may be able to access.

5. Click Save Integration to save the mapping.

At present, only users are supported (group relationships won't be mapped). You can't map an identity provider to the same IdP (for example, one Okta domain to another).

Identity Mapping Use Cases

Some common combinations for identity mapping include:

Local Users	Identity Providers
AWS IAM AWS Redshift AWS RDS MySQL AWS RDS Postgres SQL Server Trino Snowflake Custom Application (OAA data provider)	Active Directory Azure Google Workspace Okta OneLogin AWS Identity Center Custom IDP (OAA identity provider)