Veza will automatically catalog DynamoDB resources for configured AWS accounts. All discovered DynamoDB tables, secondary indexes, and streams can be viewed in the data catalog, with cross-service effective permissions available in Access Graph search. DynamoDB insights are included in select Reports, or can be viewed using the Saved Queries panel.

Notes

To extract authorization metadata for DynamoDB, the IAM policy granting discovery and extraction permissions must include the following statement:

  {
      "Sid": "DynamoDB",
      "Effect": "Allow",
      "Action": [
        "dynamodb:ListTables",
        "dynamodb:DescribeTable",
        "dynamodb:ListStreams",
        "dynamodb:DescribeStream"
        ],
      "Resource": "*"
  }

These permissions are included in the latest ; if you are upgrading from release 2021.6.xyou will need to update the policy attached to the Insight Point, IAM user, or IAM role used for discovery.

Supported Resources / Sub-resources

• DynamoDB Table

• DynamoDB Secondary Index

• DynamoDB Stream

Veza natively supports AWS Key Management Service (KMS) for all configured AWS accounts. You can use the Access Graph to display all Customer Master Keys (CMKs), and view cross-service relationships between IAM roles and policies, KMS keys, and data sources.

Any AWS tags and aliases are automatically extracted when discovering KMS keys. These can be viewed from the entity details, and used to filter search results.

Configuration

As KMS discovery is enabled by default, no additional configuration is required. For more granular control over which AWS data resources are cataloged, you can select specific services for extraction by navigating to the Veza Integrations page, and choosing the "edit" option for the AWS account.

In order for a CMK to be discoverable, its Key Policy must have IAM permissions enabled, or grant the Veza AWS IAM principal directly. are enabled by the default AWS KMS key policy, by a statement such as:

To read authorization metadata for KMS, the IAM policy used by the Veza-AWS connector must include the following statement:

The last two permissions (kms:GetKeyRotationStatus and kms:ListKeyRotations) are required to show the AWS KMS CMK "Last Rotated At" attribute in Veza.

Overview

The Adobe Enterprise integration enables Veza to discover and analyze users, groups, and administrative roles within your Adobe environment. This integration uses Adobe's User Management API (v2) to provide visibility into user access, group memberships, and product license assignments across your Adobe organization.

The integration supports:

• Discovery of Adobe Enterprise users and their properties

AWS CloudFormation allows organizations to easily deploy AWS resources into existing accounts within the AWS Organization. Veza integrates with AWS CloudFormation to enable one-touch registration of AWS accounts with the Veza platform.

To control which AWS accounts will register with the Veza platform, the provided CloudFormation template can apply to the AWS Organization as a whole, specific Organizational Units within the AWS Organization, or specific AWS accounts.

The template will create the required IAM resources and a Lambda function responsible for registering and updating the managed account where it is deployed, and create a Veza AWS Integration for the account.​

Integration Details

Overview

The Veza integration for Jenkins enables the discovery of Users and Roles, and permissions. One configured, Veza uses Jenkins APIs to populate the Access Graph with entities and metadata. The integration supports project-based Matrix Authorization and role-based access controls.

To enable the integration:

Prerequisites

• AWS IAM must be enabled

• You will need administrator privileges to create the local user, which will be used to connect at runtime

• An is recommended for RDS PostgreSQL discovery.

Granting Veza Access

There are two options to allow Veza access to RDS PostgreSQL databases, depending on whether your instance configuration has revokedpublic privileges for the pg_catalog schema, as is a common security practice.

A) If you if you have not revoked the default public privileges on your schema, you only need to create the user and grant the rds_iam privilege:

B) If you have revoked the default privileges from your schema, you should instead run the following command to create the user and grant select permissions for the required tables:

The next time Veza connects to the AWS account, the database will be registered and appear under "Discovered Data Sources" on the Integrations > All Data Sources tab.

IAM Policy for RDS Discovery

The following sections must be included in your Veza IAM policy. Update the bracketed values to contain your actual region, account ID, and the database username you specified when .

Overview

In addition to using a simple web interface to update CSV data manually, you can automate a process to push new data using the Veza REST API and refresh the Veza graph. This document includes example utilities using Python and CLI tools.

Using the Upload CSV REST API

After creating a CSV upload integration, you can use the REST API operation to upload new CSV data.

Whenever a CSV is submitted, it is processed based on the current configuration of the CSV Upload Integration provider, including any column mapping settings.Authentication: To make API calls, you must include an authorization token in the header of each request. This can be:

• A Personal API Key for a Veza administrator

• A Team API Key, for a team assigned to manage CSV Upload integrations

See for more details on creating API keys.

Note: The CSV data must be complete for each upload. Veza will remove entities from the Graph for any entities that were present in the previous upload, but not in the current upload.

Retrieving Integration IDs

Using the REST API requires the Integration (Provider) and Data Source IDs. You can retrieve these in Veza on the Integration Details > Data Source tab:

1. On the Veza Integrations page, click the CSV integration to view details

2. On the Data Source tab, click the data source name to view details

3. Copy the values from the Properties table:

   1. The unique data source "Id"

Uploading the Data

Uploading the CSV data is made with a post call to the /api/v1/providers/custom/{provider_id}/datasources/{data_source_id}:push_csv endpoint.

Note: The CSV contents must be base64-encoded into the JSON body of the request. Raw CSV values are rejected. You can automatically convert the data as part of your implementation, as shown below.

Example using Curl

Example using Python

Overview

Early Access: Beeline is available in Early Access. Please contact our support team to enable the integration.

The Veza integration for the Beeline workforce platform enables discovery of Beeline employees, and can be enabled as a source of identity for lifecycle management policies. HRIS metadata from Beeline can be used to enrich queries, access reviews, and enable provisioning and de-provisioning flows when employees are added or removed, or their status changes.

Configuring Beeline

The Veza Beeline connector uses Beeline's Reporting as a Service (RaaS) feature to retrieve employees and their attributes.

After enabling RaaS, a BeeLine report with the corresponding values must be created in advance. Please contact our support team to coordinate report creation for the latest supported attributes.

1. Ensure that the RaaS feature is enabled.

2. Generate an API key for the integration user, that Veza will use for the discovery. This user can be an existing Beeline user or a new user.

   1. Note the ClientSecret, UserName and UserAPIKey from the API Authentication Page

Configuring the Beeline Integration on Veza

1. On the Veza Integrations page, click Add Integration and locate the Beeline tile.

2. Configure the integration with the following fields:

   1. Name - Name for the integration

   2. Site ID - Customer or Project identifier for the Beeline instance

Notes and Supported Entities

Beeline Employee

Employee fields ingested by Veza will depend on the report configuration. Currently, the following attributes are supported:

• id

• employee number

• first name

• last name

Overview

Veza can discover and analyze permissions in SharePoint Server environments that are configured with Microsoft Entra ID (formerly Azure AD) federated authentication. This offers visibility into your on-premises SharePoint infrastructure using an existing Azure Integration, including:

• Site collections and sub-sites discovery

• Document libraries and folders

• Effective permission analysis

• Microsoft Entra ID user and group federation

• Optional site filtering with allow and deny lists

Prerequisites

• SharePoint Server 2013 or newer

• The SharePoint environment must be configured for federated authentication with Microsoft Entra ID following Microsoft's

• The Azure integration in Veza must be configured with a valid SSL certificate for SharePoint site discovery (Signed certificate recommended for production environments)

Configuring the Azure Integration for SharePoint Server

You can connect to SharePoint by providing a certificate for app-only access when configuring an Azure integration. For testing environments, you can generate a self-signed certificate following the .

The integration requires read-only API permissions to discover SharePoint resources:

1. Go to the Integrations page and add or edit an Azure integration, following the instructions in .

2. In Azure, create or edit the app registration for the integration with the additional API scopes:

   • SharePoint:

     • User.Read.All

If your Okta Multi-factor enrollment policies are such that traffic from Veza's Cloud IP Addresses is denied the ability to use a factor, Veza will not be able to detect user enrollment in that factor. As a result, the "MFA Active" property for Okta users will be "False," even if factors are enabled for the user. To prevent this, you can can:

• Configure an Okta Network Zone that allows optional MFA factors

• Use an Insight Point to connect to Okta from an IP address internal to your data center that does not have these restrictions

See below for more details and steps to enable:

Background

Okta have the ability to not only set enrollment but also define usage. MFA enrollment policies work by evaluating from the highest priority to the lowest priority at the policy level (filtered by groups), and then at the rule level (filtered by and ).

This means that if there is not a policy rule that fits the incoming request, Okta will check the next policy that applies to the user until it finds one (Default Policy applies to everyone and Default Rule applies everywhere).

Resolution

There are 2 options to allow Veza to fully collect MFA enrollment.

1. Configure a Network Zone specifically for the Veza IP Addresses and allow the factors as optional at the Policy level and deny the Enrollment at the Policy Rule Level:

   • Create an Okta Group to control scope during deployment.

   • Configure for under Gateway IPs.

Overview

The Veza integration for Confluent enables the discovery of Users, Groups, Roles, Clusters, and Environments from the Confluent platform. Veza uses Confluent APIs to populate the Access Graph with entities and metadata.

This document explains how to enable and create a Confluent integration. See for more details.

Overview

Concur is an enterprise-level expense management platform that automates expense reports, approvals, and payments. The integration facilitates data exchange between Veza and Concur, for user and role discovery.

Overview

The Dropbox integration enables discovery of users, groups, folders, and files within a Dropbox Business account. Veza parses group memberships and permissions to show the full range of user access on the cloud-based content management, collaboration and file sharing service.

• Access Reviews: Review user and group access to files and folders in Dropbox

Overview

The DocuSign integration enables discovery of identities, groups, and permissions within a DocuSign account. It uses Open Authorization API to create the following entities:

• Account → Custom Application

Resources and authorization for Azure SQL Database are automatically discovered for connected Azure tenants, unless the service is disabled in the .

To collect complete authorization metadata for each database, you will need to create a local database user that the app registration can connect as to execute read-only queries.

• You will need access to Azure SQL Database(s) and permission to create the local user.

• The Azure SQL Database must have an .

Overview

The Veza integration for Oracle Enterprise Performance Management (EPM) discovers users, groups and roles assigned in EPM. Veza uses an Oracle EPM service account connect to the EPM APIs to run the built in EPM reports for user group and role assignments.

RDS MySQL databases are discovered by Veza via role assumption to a local MySQL user, granted the necessary read-only permissions. Veza creates authorization entities for:

• RDS MySQL Database

• RDS MySQL Function

• RDS MySQL Instance

• RDS MySQL Local User

• RDS MySQL Local User Instance

• RDS MySQL Procedure

• RDS MySQL Role

• RDS MySQL Role Instance

• RDS MySQL Service

• RDS MySQL Table

• RDS MySQL Trigger

By default, extraction excludes the buil-in MySQL tables sys, performance_schema, information_schema, and mysql. These system-created tables are potentially of interest as they can contain sensitive data, and are discoverable on an optional basis. Enable Gather System Tables in the parent AWS integration configuration to show these Table entities and permissions in Veza.

Prerequisites

• You will need admin access and privileges to create a local user, which will be used to connect at runtime

• An is recommended for RDS MySQL discovery.

  • The Insight Point egress IP needs to be permitted in the RDS .

Support for Amazon Aurora

• RDS MySQL databases managed by Amazon Aurora are automatically discovered when RDS extraction is enabled for a configured AWS account.

• Connected instances are mapped to the top-level Aurora RDS cluster in Access Graph search.

• Since all instances in an Aurora cluster are replicas of the same MySQL database, each has the same database-level properties.

1. Configure the IAM Policy

Ensure that the IAM policy configured during AWS setup includes the <db_user> name of the MySQL user, and is the same as the RDS MySQL DB User name specified in AWS integration configuration. Below is a minimal policy allowing the required actions for discovery.

To discover individual RDS instances across multiple regions, you will need to create additional Resource entries in the Veza IAM policy for each region, for example:

"Resource": "arn:aws:rds-db:us-east-1:123456789:dbuser:*/veza_user" "Resource": "arn:aws:rds-db:us-west-1:123456789:dbuser:*/veza_user"

Alternatively, you can use wildcard operator (*) to match all regions, accounts, and databases:

"Resource": "arn:aws:rds-db:*:*:dbuser:*/veza_user"

2. Create the local user

Connect to your database, and execute the following command to create a Veza User and grant the needed privileges for discovery. Replace [veza_user] with the name of the actual database user specified in your policy:

The next time Veza connects to the configured AWS account, the RDS MySQL server will be registered and appear under "Discovered Data Sources" on the Integrations > All Data Sources tab.

Early Access: This integration is provided as an Open Authorization API (OAA) connector package. Contact our support team for more information.

Auth0 IdP OAA Connector

Overview

The OAA connector for Auth0 populates an OAA Custom Identity Provider with discovered Auth0 Users. These identities can be mapped to other configured Veza data sources (Snowflake, Trino, etc.), or resources in other OAA Custom Applications.

Collected Attributes

Setup Instructions

Auth0

1. Create a new application

   1. Provide the application a name

   2. Select "Machine to Machine Applications and click Create

   3. Select the

Veza

1. Generate an API key for your Veza user. API keys can be managed in the Veza interface under Administration -> API Keys. For detailed instructions consult the Veza User Guide.

Running the connector

Command Line

1. With Python 3.8+, install the requirements into either a virtual environment or the system.

2. Set the Veza API key, Auth0 Client ID, and Secret environment variables:

3. Run the connector:

Parameters

The recommended AWS connector policy only includes API permissions to get authorization metadata for Redshift clusters. To connect to Redshift databases for full discovery, a local Redshift user with the redshift:GetClusterCredentialsIAM privilege is required. You can allow this via IAM policy in one of two ways, described in the steps below.

Additionally, the local user will also need read-only database permissions on the warehouses to discover.

1. Update AWS IAM policy

A) AWS can automatically create a local user with the same name as the IAM principal initiating the connection. This can be accomplished in your policy using the condition key ${redshift:DbUser}, as in line 6 of the following example:

Note that the name of the provisioned Redshift user will be transformed to lowercase, and any dashes will be replaced with underscores (For an IAM user or role Veza-AI, the Redshift user name will be veza_ai).

B) If you would prefer to connect as a local user that you will create yourself, you must specify that user explicitly in the policy, for example:

Connect to the Redshift warehouse and create the user:

2. Grant Redshift database permissions

The redshift-data:ExecuteStatement only allows the Veza service principal to run Redshift queries—the exact data Veza can access is governed within Redshift. Database permissions must be granted to the local user for each instance you want to discover.

Connect to the data warehouse and use the following GRANT SELECT command:

The next time Veza conducts discovery for the parent AWS account, the instance will be registered and appear under "Discovered Data Sources" on the Integrations > All Data Sources_ tab.

Overview

The Veza integration for Delinea Secret Server enables the discovery of Users, Groups, Roles, and permissions from the Delinea Secret Server platform. Veza uses Delinea APIs to populate the Access Graph with entities and metadata.

This document explains how to enable and create a Delinea Secret Server integration. See notes and supported entities for more details.

Configuring Delinea Secret Server

Before adding the integration to Veza, create or select a user account for the connection.

To create a single user on the Delinea Secret Server platform, browse to your Delinea instance as an administrator, go to Admin -> User Management, then select Create User

Once the user account has been created or identified, record the username and password for the account, then ensure that the account is assigned the following roles:

Configuring Delinea Secret Server on the Veza Platform

To enable Veza to gather data from the Delinea Secret Server platform:

1. In Veza, open the Integrations page.

2. Click Add New and pick Delinea as the type of integration to add.

3. Enter the required information and Save the configuration.

Notes and Supported Entities

The connector discovers the following entities and attributes:

Delinea Secret Server User

Delinea Secret Server Group

Delinea Secret Server Role

The Veza integration for LastPass Enterprise connects to the platform to discover users, groups, roles, and folders used to store and share passwords and other secrets. Use the integration to:

• Search for LastPass users and shared folders, and create rules and alerts.

• See effective permissions within LastPass for users and groups, based on their roles.

• Review LastPass user > group, user > folder, and user > role assignments.

Requirements

The connector uses the LastPass Enterprise API to fetch authorization metadata. You will need a LastPass account number (cid) and provisioning hash (prohash) to authenticate. To retrieve these values, log in to LastPass using an account with permission to access the Admin Console at .

• Account ID: Unique Account ID provided by LastPass. This can be retrieved on page:

• Provisioning Hash: This API secret can be generated on the LastPass Admin page. Go to to manage provisoning hashes.

You can use an existing provisioning hash, which is unique for your organizations LastPass Enterprise API. If you cannot retrieve the current value, you will need to regenerate it and update any other applications to use the new hash.

See for the latest guidance from LastPass.

Veza setup

To enable Veza to gather data from the LastPass platform:

1. Browse to your Veza instance

2. In the left navigation, expand Configuration, then click Integrations

3. In the main pane, click Add Integration. Pick LastPass.

4. Enter the required details:

Notes and supported entities

LastPass User

Veza discovers and shows the following metadata for LastPass User entities. Attribute filters can be used to constrain searches and access reviews based on these properties:

LastPass Group

Veza discovers and shows the following metadata for LastPass Group entities. Attribute filters can be used to constrain searches and access reviews based on these properties:

LastPass Folder

LastPass folders have the following attributes:

LastPass Application Roles

The Veza LastPass integration discovers the user's role in LastPass as either Admin or User. LastPass does not currently return information about customer-created Admin Levels. Any admin-level user will be assigned the Admin role for the LastPass application. All other users will be assigned the User role.

LastPass Folder Roles

Users assigned to a Shared Folder (either directly or by group membership) have Roles based on the configuration of permissions on the assignment.

Veza creates these Access Graph entities to represent access controls enabled when managing Shared Folder recipients in LastPass:

A user may have multiple roles on a folder based on the pairings of these permissions.

The Veza integration for BambooHR connects to the HRIS platform to discover user profiles and attributes, and group assignments within the application. BambooHR users typically access the platform to track hours worked, manage benefits enrollment, and administer payroll from a single platform. Use the integration to:

• Search for users and filter the results based on metadata Veza collects.

• Review user > group assignments within BambooHR.

• Create alerts and rules to alert for changes in user attributes such as Activity Status.

Requirements

The connector uses the BambooHR Reports API to gather the required authorization metadata. To enable the connector on Veza, you will need to supply an API key and the company domain to connect to:

• Company Domain: The name of the company from your BambooHR login URL: https://{company_domain}.bamboohr.com/.

• API Key: Unique API Key provided by BambooHR. Each user can have one or more secret keys that identify that user to the API. The secret key is a 160-bit number expressed in hexadecimal form.

To create an API key in BambooHR, follow these steps:

1. Log in to BambooHR and click on your name in the upper right corner of any page to open the user menu. Optionally, you can create a dedicated BambooHR user for the integration, and complete these steps after logging in as that user. Note that users must have Full Admin access to create API keys.

2. Click API Keys.

See for official documentation on creating BambooHR API keys.

Adding a BambooHR Integration to Veza

To enable Veza to gather data from the BambooHR platform:

1. Browse to your Veza instance.

2. In the left navigation, expand Configuration, then click Integrations.

3. In the main pane, click Add Integration and choose BambooHR.

4. Enter the required details:

Notes and Supported Entities

Veza discovers and shows the following metadata for BambooHR User entities, which can be used to narrow searches and access reviews using attribute filters:

This integration is provided as an Open Authorization API (OAA) connector package. Download the source code on GitHub.

Looker OAA Connector

Overview

OAA connector for Google Looker focusing on Looker Models and Connections. Discovers Looker users and groups and provides authorization data for the Looker Models and database connections users can access based on their Looker roles.

OAA Application Mappings

This connector uses the OAA Application template. The following table shows how Looker entities are mapped to the template.

Attributes

Looker connector extracts the following attributes:

User:

• id - Looker ID

• verified_looker_employee - Boolean for user is identified as an employee of Looker who has been verified via Looker corporate authentication

• presumed_looker_employee - Boolean for User is identified as an employee of Looker

Group:

• id - Looker ID number

Model Set:

• id - Looker ID number

• built_in - Boolean for if model set is built in

• all_access - Boolean if the model set is configured to include all models

Connection:

• dialect - JDBC dialect connection is configured as

• host - Database connection host

• username - Database connection user name

Setup

Prerequisite

1. Generate a Looker API3 key for a user with sufficient privileges to see all users, roles and models. The following scopes are required:

   1. see_users

   2. manage_models

Command Line

1. With Python 3.8+ install the requirements either into a virtual environment or otherwise:

2. Export the Veza API keys and Looker connection information to the OS environment.

3. Run the connector

   Optionally export the Veza URL to the environment as VEZA_URL and run with no parameters required.

This guide provides platform-specific examples for configuring LDAP servers to allow read-only access for the Veza integration. Configure your LDAP server to provide the minimal permissions required for Veza to discover users, groups, and their relationships.

OpenLDAP Configuration

OpenLDAP uses Access Control Lists (ACLs) defined in slapd.conf or through dynamic configuration. The service account needs read access to the target organizational units.

Example ACL Configuration:

Service Account Creation:

Oracle Unified Directory Configuration

Oracle Unified Directory uses Access Control Instructions (ACIs) for permission management. Configure through Oracle Directory Services Manager or command line.

Example ACI Configuration:

IBM Directory Server Configuration

IBM Directory Server uses ACLs similar to other enterprise LDAP implementations. Configure through the IBM Directory Server Web Administration Tool.

ACL Example:

ForgeRock Directory Services Configuration

ForgeRock Directory Services uses ACIs similar to Oracle Unified Directory. Configure through the ForgeRock Directory Services Control Center.

Example ACI Configuration:

Red Hat Identity Manager Configuration

Red Hat Identity Manager (IdM) uses groupOfNames object class with member attributes instead of the default groupOfUniqueNames with uniqueMember. Configure the Veza integration with these specific settings:

• Groups Object Class: groupOfNames

• Group Member Attribute: member (or leave blank for auto-detection)

IdM provides built-in permission and role management through the ipa command-line interface. Create appropriate permissions for the Veza service account to read user and group information according to your organization's IdM configuration policies.

General Security Considerations

When configuring any LDAP server for Veza integration:

1. Principle of Least Privilege: Grant only the minimum read permissions necessary for user and group discovery

2. SSL/TLS Encryption: Always use LDAPS (port 636) or StartTLS to encrypt communication

3. Service Account Security: Use a dedicated service account with a strong password and appropriate expiration policies

4. Network Security: Ensure the LDAP server is accessible only from authorized Veza components

Testing Configuration

After configuring your LDAP server, verify the service account can access required data:

Consult your LDAP server documentation for platform-specific configuration details and best practices.

Reteriving Signing Certificate

Many LDAPS deployments use a locally signed certificate for encrypting the traffic in-flight. The singing Certificate Authority (CA) must be provided during configuration for Veza to trust the connection.

The CA can be retrieved from the server using openssl tool to inspect the signing certificate for the connection.

The command will output summary information about the signing certificates in the connection. Copy the base64 encoded text between the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- to a text file. if there are multiple certificates, each can be added to the same file. Save this file and upload it for the Ca Certificate during configuration.

Overview

The Veza integration for BlackLine enables gathering User, Group and Role assignments from the BlackLine financial automation platform.

Configuring BlackLine

1. Create a BlackLine user for API access

   • The user must have the API Role and be a System Administrator to make the necessary requests

2. Generate an API key for the user for the BlackLine API Administration Portal or Financial Close System

3. Request OAuth 2.0 credentials from the BlackLine customer support team:

For more detail on obtaining credentials and BlackLine API keys, see in the official developer documentation.

Configuring BlackLine on the Veza Platform

1. On the Veza Integrations page, add a BlackLine Integration with the following fields:

   • Name - integration name

   • URL - URL for BlackLine instance from installation form e.g. https://us.api.blackline.com

NOTE: Please contact Blackline Customer Support if you need the values for URL, Username, API key, Client ID, Client Secret and Instance ID.

Notes and Supported Entities

BlackLine Users

BlackLine Group

BlackLine Product (as Resource)

BlackLine Role

Roles are assigned to Users or Groups to either BlackLine Application or specific BlackLine Product (resource) as configured in BlackLine.

Overview

The Veza integration for the Ivanti Neurons HRIS system streamlines identity governance by automatically synchronizing employee data with Veza's Identity Security platform. This integration enables organizations to:

• Maintain current employee data across your identity security infrastructure

• Enrich Veza search results with up-to-date employee information

• Streamline access reviews with accurate organizational context

• Support automated lifecycle management workflows using Ivanti Neurons as a source of identity

This guide will walk you through creating the required API credentials in Ivanti, configuring the integration in Veza, and including custom employee attributes (optional).

Configuring Ivanti

The Veza Ivanti Nurons connector requires an API key to connect and collect the employee information. Follow the steps in the Ivanti

Create the API key for a user with administrative read permissions to view all employees.

Configuring the Ivanti Nurons Integration on Veza

Most customers will require a Veza Insight Point to be deployed in their environment to access their Ivanti Nurons instance. Follow the steps <> for more on deploying a Veza Insight Point.

1. On the Veza Integrations page, click Add Integration and locate the Ivanti Nurons HR tile.

2. Configure the integration with the following fields:

   1. Set the Insight Point - Select the Insight Point that will have access to the Ivanti Nurons instance

   2. Name

Notes and Supported Entities

Ivanti Employee

The Veza connector gathers employee metadata from the employees business object. Business Objects can be viewed from the Ivanti Configuration console, under Build > Business Objects

The following Employee properties are collected by default and mapped to the Veza Employee object.

Collecting Additional Fields

Any additional field from the employee business object can be extracted as a string by adding it to a comma-separated list in the Additional Properties field during integration configuration. These values will be added as custom properties on the Employee object shown in Veza.

For example, to collect the employees DN and extensionAttribute1 set Additional Properties to DN,extensionAttribute1

The Veza integration for Egnyte enables the discovery of Users, Groups, and Roles from the Egnyte platform. Veza uses Egnyte APIs to populate the Access Graph with user, group, and role information. Use it to:

• Find users and groups roles within a Workspace.

• Find identities with specific permissions in Egnyte.

Note that resources such as individual channels are not discovered. While Veza collects role information, the associated permissions with the roles will not be found in the connector.

Egnyte Setup

Before adding the integration to Veza, you need a token to make authenticated requests on the Egnyte platform:

1. Get the application API key for your application. Log in to developers.egnyte.com, and go to your profile. Search for Keys.

   • Ensure the API key user has admin-level permissions. Veza will only use the necessary scopes, which are egnyte.user, egnyte.group and egnyte.permissions.

Veza Setup

To enable Veza to gather data from Egnyte:

1. Log in to your Veza platform.

2. Go to Integrations.

3. In the main pane, click Add Integration > Egnyte.

4. Enter the required fields:

Supported Entities

Veza creates the following entities to represent Egnyte identities and access controls, along with some additional attributes:

Egnyte User

Egnyte Role

Egnyte Group

Overview

The Veza integration for Oracle Fusion Cloud supports collecting Users, Groups, and Roles for the Oracle Fusion Cloud ERP platform.

See for more details.

Configuring Oracle Fusion

Veza uses pre-defined reports in Oracle Fusion to collect user role information. These reports are defined in an Oracle Fusion catalog file that can be downloaded below.

1. Create a user for the connector to use. The connector uses that user name and password combination to connect to both the Oracle Fusion REST API and BI Publisher.

2. Upload the Veza_v2.catalog file to the BI Catalog.

   1. Navigate to the instance's Catalog page: https://<instance>.oraclecloud.com/analytics/saw.dll?catalog

Configuring Oracle Fusion Integration on Veza Platform

1. In Veza, open the Integrations page.

2. Click Add New and pick Oracle Fusion Cloud as the type of integration to add

3. Enter the required information and Save the configuration

Notes and Supported Entities

Oracle Fusion Cloud User

Oracle Fusion Cloud Role

Oracle Fusion Security Context (as Resource)

Oracle Fusion Security Contexts (e.g. 'Asset Book', 'Business Unit', 'Ledger') are represented as Resources. Users may have specific roles assigned to specific Security Contexts in addition to application-wide roles.

Lifecycle Management Support

Oracle Fusion Cloud also supports automated Lifecycle Management including provisioning, deprovisioning, and role assignment management through the Oracle SCIM API. For information see the .

Overview

The Veza integration for Expensify enables discovery of users, workspaces, and roles within the expense management system.

Use it to:

• Search for any Expensify user by department or who they submit expenses to.

• Review Expensify Role and Workspace assignments for all users or specific Workspaces.

• Create rules and alerts when changes occur (such as when a new Policy Admin is detected or a Workspace is added).

See for more details.

Configuring Expensify

The integration uses the Expensify Enterprise Import/Export API to fetch the data.

• To connect, Veza will need your Expensify partnerUserID and partnerUserSecret.

• Veza recommends creating a unique user and using their API credentials for the integration. The integration user should have the AUDITOR role to gather the required authorization metadata.

To get the User ID and User Secret, log in to Expensify and go to the Integrations page: https://www.expensify.com/tools/integrations/.

• If you've already generated these for another application, you will need to use the existing ID and Secret. Otherwise you can regenerate the credentials.

• See the for more details.

Configuring Expensify on the Veza Platform

1. In Veza, open the Integrations page.

2. Click Add Integration and pick Expensify as the type of integration to add

3. Enter the required information and Save the configuration

Notes and Supported Entities

Veza creates Access Graph entities to represent Expensify Users and Expensify Groups. You can create filters and rules based on the following attributes.

Expensify Users

Expensify Users represent individual employees who log to report or approve expenses, or any other task on the platform.

Expensify Workspaces (as Groups)

Expensify Workspaces define common rules for expense management, used to organize departments, teams, or other groups of users.

Expensify Roles

Roles define the relationship an individual users has to a Workspace, such as Policy Admin, Auditor or Employee, and represent a set of permissions.

Description

Validates that the service account used for a has the required permissions. Rather than checking a specific policy, Veza will verify the total permissions granted to the service account used for extraction.

Overview

The Veza integration for Kubernetes enables gathering information about the RBAC roles existing in a cluster, and who has permissions on Kubernetes services and resources.

The integration supports self-hosted deployments and managed Kubernetes services. If you've also integrated Microsoft Azure or Amazon Web Services with Veza, the Kubernetes integration can show authorization relationships connecting users and Kubernetes services, clusters, and roles.

For example, for AWS EKS, the integration provides visibility into:

The HiBob integration connects to your HiBob HR Information System (HRIS) platform to gather employee metadata and organizational structure information. As a primary source of workforce identity data, HiBob provides context for understanding user access patterns and supporting identity lifecycle decisions.

The integration enables:

• Employee data synchronization for Lifecycle Management.

• Visibility into HiBob structure and employee status.

Overview

The Veza integration connects to Jamf Pro to discover Users, Groups, and Sites. Jamf is typically used for deploying and maintaining software, responding to security threats, distributing settings, and analyzing inventory data. Enabling the integration lets you use Veza to visualize, audit, and create rules for users with privileged access to Jamf, and their group and role assignments.

Overview

The Veza MySQL integration provides visibility into database security posture by discovering local users, roles, resources, and permissions within a MySQL instance. This integration enables security teams and database administrators to:

• Map and monitor access across databases, tables, triggers and routines

This integration discovers Users, Groups, and Projects for GitLab software development platform, along with authorization data for each group and projects. The integration supports self-hosted and SaaS GitLab deployments.

The GitLab integration requires a read-only access token for authentication, and will discover all groups, sub-groups, and projects the token can access. For self-hosted (non-SaaS) environments, you can optionally discover all groups and additional user information by providing an admin token.

See for more information.

Setup