Identity Provider and HRIS Enrichment

Create access reviews to include information from an integrated identity provider or human resource information system.

Early Access: Enrichment is currently provided on an opt-in basis. Please contact Veza Support to enable this feature. Enrichment requires an IDP or HRIS integration such as Okta, Active Directory, Azure AD, Workday, or a Custom Identity Provider.

Overview

You can configure access reviews to show additional human resource or identity metadata for users under review. When enabled, Veza will check for matching entities in an integrated Identity Provider or HRIS platform when creating the review. The linked user attributes are shown in columns, which reviewers can show, hide, or filter by for faster and more accurate decision-making.

Optional IDP User columns in the reviewer interface.

For example, when reviewing local Snowflake user access to Snowflake databases, enabling this option will show the attributes of the linked Okta user for each local user, such as their risk score, first and last name, and whether MFA is enabled. Local users with no linked Okta users could be machine identities, or represent risky misconfigurations.

Similarly, an access review of Okta users to Okta applications can use this option to show information about the Workday Worker associated with each user, such as the cost center, hire date, or active status.

Enabling IDP/HRIS Metadata Enrichment

To enable IDP User columns in the reviewer interface, enable enrichment in the configuration scope:

1. Create or edit a configuration.

2. In the review scope, enable Advanced Options > Enrich with IdP/HRIS data.

3. Select from the list of supported entity types to enable result enrichment (such as "Workday Worker" for "Okta User"):

   

   Choosing an entity type for enrichment.
4. Save the configuration and create a review.

5. In the reviewer interface, use the column selector to enable columns for the "IDP User."

   

   Enabling IDP User columns in the reviewer interface.

   To configure the reviewer interface to show these columns by default, see Customizing Default Columns.

Filters on IDP/HRIS Enrichment

In the configuration builder, choosing an entity type under the Enrich with IdP/HRIS data option enables filters on that entity type. For example, you might choose 'Okta User' as the source entity type under review and enable 'Workday Worker' as the enrichment entity type. You can then apply filters on both Okta User and Workday Worker attributes.

It is important to understand how these filters affect the review results. If an enrichment attribute does not meet the filter criteria, the enrichment data for that row is hidden, but the original access relationship remains visible. This behavior ensures that you can still see all source and destination entities, and identify rows where the enrichment data does not match the filter.

• Filters on enrichment data do not remove source or destination entities from the review. You will still see all access relationships.

• If the enrichment data does not meet the filter criteria, only the enrichment columns are affected.

• This behavior helps identify users who may not have corresponding enrichment data, potentially presenting misconfigurations.

Example:

Suppose you have a review of Local Users to Local Groups, enriched with Okta User data:

Okta User	Local User	Local Group
Bob	Bob	Group1
Bob	Bob	Group2
Alice	Alice	Group2

Now, you apply a filter on the Okta User column to exclude users whose names start with "A" (e.g., Okta User does not start with "A"). The updated review results will be:

Okta User	Local User	Local Group
Bob	Bob	Group1
Bob	Bob	Group2
(blank)	Alice	Group2

In this filtered view:

• Bob's enrichment data continues to appear because it meets the filter criteria.

• Alice's enrichment data is blank because it does not meet the filter criteria (Alice starts with "A").

• The access relationship between Alice and Group2 remains visible.

Using Enrichment Data in Automations

When you enable IdP/HRIS enrichment for an Access Review configuration, the enriched entity data is available for use in Intelligent Automations. This enables automation scenarios such as automatically rejecting access for users without a matching identity provider profile.

Early Access: Using enrichment data in Automation filters is currently in early access. The API validation may reject some filter expressions involving enriched entity aliases. Basic filters on source.* and destination.* attributes are fully supported in Automations. Contact Veza Support for the latest status on this feature.

Understanding Enrichment Aliases

Each enriched entity type in your review configuration is assigned an alias that you use to reference its attributes in automation filters. The alias is a short identifier defined when the Access Review configuration is created. Common conventions include simple names like idp or hris, or snake_case versions of the node type like okta_user.

Important: When referencing enriched entity attributes in automation filters, use the alias directly (e.g., idp.department). Do not use joined_nodes.idp.department. The joined_nodes prefix appears in result data but is not valid in filter syntax.

Finding the Alias for Your Configuration

The alias for enriched entities is set when the Access Review configuration is created and varies by configuration. To find the correct alias for your specific Access Review:

1. Check API responses (recommended): Call the List Certifications endpoint for your workflow. The response includes the query_spec with join_connected_specs that shows the as field value for each enrichment.

2. Inspect browser network responses: When viewing a review in the Veza UI, open browser developer tools (F12) and examine the network responses. Look for:

   • The query_spec object containing join_connected_specs with as field values

   • The joined_nodes map in result data, where the keys are the aliases

The Query Builder UI displays friendly names (e.g., "Okta User") in column headers. The underlying alias can differ. Always verify the actual alias from the API or network responses before writing Automation filters.

Automation Filter Examples

Once you know the alias, you can create automation filters that reference enriched entity attributes. These examples use idp as the alias. Replace this with the actual alias from the review configuration.

Automation filters use SCIM syntax, which does not support regular expressions. Use sw (starts with), ew (ends with), or co (contains) for partial string matching.

Check if an enriched user exists:

idp.idp_unique_id pr

Check if an enriched user does NOT exist (orphaned account detection):

not (idp.idp_unique_id pr)

Filter by an enriched attribute:

hris.department eq "Engineering"

Combine source and enrichment filters:

source.identity_type eq "HUMAN" and not (idp.idp_unique_id pr)

Combine custom properties with OR logic and enrichment filters:

(source.customprop_attr_code eq "100" or source.customprop_attr_code eq "200") and not (idp.idp_unique_id pr)

Example: Auto-Reject Orphaned Accounts

This automation automatically rejects local accounts that have no matching identity provider profile, helping identify potential security risks. Replace idp with your actual enrichment alias.

{
  "name": "Reject Orphaned Human Accounts",
  "description": "Auto-reject local human accounts with no associated IdP profile",
  "priority": 1,
  "attachment_behavior": {
    "attach_to_new_workflows": true,
    "opt_in": true
  },
  "criteria": {
    "filter": "source.identity_type eq \"HUMAN\" and not (idp.idp_unique_id pr)"
  },
  "action": {
    "decision": "REJECTED",
    "signed_off_state": "UNKNOWN_SIGNED_OFF",
    "notes": "Local user has no IdP profile"
  }
}

For complete documentation on creating and managing Automations via the API, see Automations API.