Custom Identity Provider

Use this template to model authorization metadata for custom identity providers using the Open Authorization API.

This document includes an example template and notes for designing and publishing a model of your IdP.

• domain

• users

A can define additional properties, used to add supplemental metadata to entities in the payload.

Veza will handle federated identities just as those in supported IdPs such as Okta or Entra ID, enabling search and access review for OAA entities alongside the rest of your data catalog.

Sample Template and Features

The metadata payload describes the Identity Provider domain, users, and groups to add to the Veza Access Graph:

Modeling Assumable Amazon Web Services Roles

For cases where federated IdP entities are granted AWS permissions via IAM roles, the template supports defining assumable roles per-user. Binding a custom IdP user or group to an AWS role or group ARN enables Veza to parse and display the resource-level actions permitted within AWS.

Custom IdP users and groups can be assigned permissions in other OAA applications by setting the principal type to idp in identity_to_permissions in the payload.

Source Identity Assignments

For use cases where a custom IdP is federated with another identity provider user identities can be linked between the two. Authorizations granted to the user will also be granted the source identity. The link is created by providing the unique identity ID and provider type as part of the user entry.

For provider_type the following values are accepted:

Resource Manager Assignments

New in Veza release 2022.2.1

To assign an IdP user or group as the manager of any resource Veza has discovered, list the node type and node id in the entities_owned field, for example:

When parsing the payload, resources in the data catalog will be updated with a SYSTEM_resource_managers tag to enable entitlement reviews. The owner(s) will be suggested as reviewers for Veza Workflows that target an individual named resource with the correct tag.

Manager Assignments

Users and groups can be mapped to the identity of another user they report to. When configured, the manager will be suggested as a review for Workflow certifications where the assigned reporter is the single query target "named entity."

Custom Properties and Tags

are the recommended method for adding additional metadata to custom identities and resources.

Additionally, can be applied to the IdP domain, users, and groups:

Use incremental updates to remove tags: Resubmitting a payload with different tags will apply any new tags, but not remove existing ones. To remove a tag already applied to an entity, you will need to use the remove_tag operation.

Incremental Updates

After the initial metadata push (which must contain the full payload), you can modify, add, or remove the domain, users, and groups without resubmitting other entities. An is enabled by setting "incremental_change": true in the json_data push payload, and specifying the update operation for each entity to change.

Custom Identity Provider definition

The identity provider object models one instance of the custom IdP:

IdP Domain

One domain is supported for each custom IdP. Users and groups are mapped to the IdP domain, and connected in Veza Search:

IdP Users

Each IdP user object contains the display name, login email, and identity, along with other identity-related properties:

IdP Groups

Add a group by name in the groups section of the template to enable mapping IdP users to those groups:

IdP entities can be granted permissions on custom applications in the identity_to_permissions section of the .

IdP Apps

Use the apps section to define any applications used to manage access within the identity provider. Apps can be associated with users and groups to model application assignments across your organization.

Users and Groups can be assigned to an application by setting the app_assignments in the user or group.

Creating and Updating a Custom Identity Provider

The steps to add a custom IdP are the same as for any other OAA provider: you will need to register the new provider and data source, and then push the domain, user, and group descriptions in a JSON payload.

Register a custom identity provider

To create a new custom provider using the identity_provider template, POST the name and template type to /providers/custom:

The response will return the custom IdP ID, which you will need when pushing the metadata payload:

Push a data source for the custom identity provider

Note that the provider id is required in both the path and body of the request. The response will include the new data source ID.

Push metadata for the data source

The payload file must contain the provider and data source ID, and the authorization metadata as a single string, for example:

Identity Mapping Configuration

The identity_mapping_configuration parameter defines rules for connecting users in a custom IdP to users from other data sources in the Veza graph.

This is useful when:

• The connected data source does not natively support returning information about external identities

• A correlation between IdP identities and local users can be assumed based on values like username, email, or another property value.

The identity_mapping_configuration is a top-level property of the Custom IDP submission, and is optional. The mapping configuration can include multiple mappings to connect IDP users to users from different data source types, each based on its own mappings.

Incremental Identity Mapping Updates

You can update just the identity mappings without resubmitting the entire provider payload by using an incremental update. This is useful when you need to modify only the mapping configuration while leaving other provider data unchanged.

Example curl command to apply the incremental identity mapping update:

Identity Mapping Configuration

Identity Mapping Submission

Supported transformations:

• IGNORE_SPECIAL: Ignore special characters (_, -, .) when matching identities

• IGNORE_DOMAIN: Match identities after removing domain portions (e.g., "@example.com")

IdentityMappingPropertyMatchersSubmission