To send notifications to a Slack workspace, you will first need to configure a simple Slack application. You can then add the Slack app's incoming webhook URL on the Veza Integrations > Veza Actions page.

Create a new Slack app

You will need an incoming webhook URL, which you can generate by setting up a new Slack app:

1. Create a new app (https://api.slack.com/apps/new) by choosing Build App > From Scratch.

2. Give the app a name and select a workspace, and click Create App.

3. On the app settings screen, choose Incoming Webhooks > Enable. Click “Add New Webhook to Workspace.”

4. Pick a channel the webhook will post to, and click Allow.

5. Copy the webhook URL.

Add a Slack Veza Action to Veza

After you have the incoming webhook URL, you can enable notifications:

1. Browse to Veza Integrations > Veza Actions > Add Veza Action

2. Click Slack and click Next.

3. Add a name and paste the webhook URL from the previous steps.

4. Click Next to test the configuration. You should see a sample message in the workspace channel assigned to the Slack app.

5. Click Create Veza Action to save it.

Overview

Veza requires your IdP to send specific user attributes in the SAML or OIDC token.

• Email: The user's email address. This is the unique identifier for the Veza user.

• First (Given) Name: The user's first name

• Last (Family) Name: The user's last name

• Groups: The user's groups. This is used to assign the user to teams in Veza.

The names of these attributes may vary depending on your IdP. For example, the User's first name is firstName in Okta and givenName in Azure. The attribute mapping feature allows you to map your IdP attributes to Veza user attributes.

Defaults

Default values are applied when no user mappings are provided. Once a mapping is provided, the default value is ignored.

For OIDC, we provide the option to read the ID token or access token.

The Veza administration section provides tools for securing your tenant, managing users, configuring single sign-on (SSO), and monitoring system events. Because Veza analyzes and stores sensitive information about your organization's identities, permissions, and resources, you should properly secure your Veza tenant before adding integrations and users.

Options for managing cloud provider and data source integrations are available from the Integrations page. Use the Integrations > Veza Actions page to set up external destinations for alerts and event notifications.

Before proceeding with any additional configuration:

1. Secure your tenant by configuring SSO, MFA, and local account policies.

2. Review Veza's user management options and role-based access controls.

3. Monitor Veza platform events.

Administrative Features

Click Administration on the main Veza navigation menu to configure global settings for the Veza platform:

• Platform Events: Review platform events, such as user logins, role changes, and changes to API keys.

• User Management: Create and manage user accounts and roles.

• Team Management: Create teams with limited scopes.

• Sign-In Settings: Set up and manage SSO integration and access policies.

• API Keys: Configure API authentication for automated access.

• System Settings: Adjust activity monitoring timeframe, domain filter rules, and integration extraction and discovery interval.

• Support User Access: Enable restricted temporary access for Veza support personnel.

Integration Management

After securing your tenant and verifying all security configurations, you can begin adding integrations:

• Configure identity provider (IdP) connections.

• Set up cloud platform integrations for services like AWS, Google Cloud, or Microsoft Azure

• Establish Insight Points for internal resource discovery.

• Configure Veza Actions for external integration and automation.

New integrations can take some time to complete their initial scan. The Integrations page overview and integration details will show the synchronization status. See Configuring Integrations to learn about managing and monitoring Veza integrations.

Additional Resources

• Integration guides

• API documentation

• Access Reviews Settings

• Enrichment Rules

Overview

Veza supports OpenID Connect (OIDC) for Single Sign-On (SSO) authentication.

Enabling OIDC

1. Copy the Client ID from your IdP

2. In Veza navigate to Administration > Sign-in Settings, and click Configure under Enable OpenID Connect

3. Enter the Idp Issuer URL (e.g. https://oktadomain.okta.com)

4. Select Private Key JWT or Secret as the Auth Method method

5. Update your IdP with keys or secrets from Veza

6. Verify attribute mappings

7. Add optional role mappings to assign users to Veza teams and roles based on IdP group assignments.

8. Click Confirm to finalize the configuration in Veza

Auth Method

We provide two client authentication methods for OIDC:

• Shared secret

• Private Key JWT - recommended for production use

The Shared secret option will require you to provide a client secret. This is a shared secret between Veza and your IdP.

Selecting the Private Key JWT option will reveal a URL containing your instance's public key. You must configure your IdP to fetch this URL.

Configuration

You can enable optional parameters when configuring OpenID Connect:

ACR Values

The acr_values parameter is used to specify the authentication context class reference values. This is an optional parameter that can be used to request specific authentication methods or levels of assurance from the Identity Provider (IdP).

RP Initiated Logout

RP Initiated Logout is a feature that allows the relying party (RP) to initiate the logout process.

Enabling this option will reveal a URL for your IdP to initiate logout.

Resource

The resource parameter is used to specify the resource that the client is requesting access to. This is an optional parameter that can be used to request specific resources from the Identity Provider (IdP).

Attribute Mapping

When configuring OIDC, you can map user attributes from your IdP to Veza. The following attributes are supported:

See Attribute Mapping for details on how to configure attribute mapping for SSO users.

Teams (Role Assignments) with Single Sign-On

Role mapping allows you to assign teams and roles based on a user's groups during login.

See Role Mapping for details on how to configure teams and roles for SSO users.

Use the Integrations > Veza Actions page to customize outbound destinations for Veza events. Outbound integrations on this page can be chosen when configuring Veza Actions for Access Reviews and rule-based alerts for saved queries. You can use a Veza-provided integration or use a webhook to enable custom integrations.

Built-in integrations are available for:

• Slack

• Jira

• ServiceNow

• Webhook

• Email notifications

Email notifications

To send an email when a rule is triggered, add a Veza Action:

1. Go to Integrations > Veza Actions.

2. Click Create Veza Action.
3. Choose Email and click Next.

4. Give the action a name and type in a single email address. Click Next.

5. Test the configuration and and click Create Veza Action.

For Access Reviews, see Email Notifications and Reminders and Veza Actions for Access Reviews to configure these at the review or configuration level. See Notification Templates to customize email content for Access Reviews.

Overview

You can use the Jira Veza Action to automatically create a ticket when Veza detects changes in relationships or properties of Authorization Graph entities. You can set Jira as the destination for alert notifications by configuring a for a . Access Reviews support Jira as a destination when a rejected row is signed-off, enabling other teams to track and follow up on remediation actions.

Requirements

To configure the connection, you will need:

• A Jira user with permission to create tickets in a specified project.

  • This user will also need permission to set any issue fields configured in the Additional Fields step.

• A username for the Jira user.

  • In Jira Cloud, the username is the email address associated with the desired user.

  • In Jira Data Center, the username is not an email address. Jira Data Center APIs require the proper Username for the user.

• An access token for the Jira user.

  • In Jira Cloud, this is an .

  • In Jira Data Center, this is a .

• A Jira project code (such as EAC).

• (optional) A Jira username of a user to assign tickets to. This can be the same as the user created for the Veza Action.

Configure Jira Veza Action

Add a connection to Jira Cloud or Data Center on the Veza Veza Actions page:

1. Click Add Veza Action > Jira.

2. Enter the required details:

   • Name (required): Friendly name to identify the connection on the Veza Actions page.

   • Host (required): URL of the Jira application, for example, https://your-org.atlassian.net.

   • Username (required): Jira username for creating tickets, set as the reporter in Jira.

   • Token (required): Jira API token for the Veza Action user.

   • Project (required): Project to create the issue (for example TMP).

   • Issue Type (required): of the created issue (e.g. bug).

   • Default Assignee (optional): Jira username to assign tickets created by the Veza Action user.

3. Click Next to configure optional Additional Fields.

   • System Fields are standardized Jira-defined fields (e.g. Component).

   • Custom Fields are unique to each Jira instance, with behavior defined by their individual .

4. Click Next to test configuration. Click Create Veza Action to save it.

Limitations and troubleshooting:

• An error will occur if your Jira configuration requires unsupported fields to create issues in a project.

  • Veza currently only supports a subset of System Fields and Custom Field Types. This subset is represented in the available selectors in the wizard.

• Custom issue types are not currently supported. Issues can have any basic issue type (typically "Task" or "Bug").

By default, Veza employees cannot access customer tenant data. To troubleshoot issues with assistance from the Veza support team, you can create a short-lived support user account with limited teams and roles in your environment. This account expires automatically after a specified duration, ensuring security and compliance with organizational policies.

Upon expiration, the support account is automatically disabled and removed from the Users page. You can re-enable the account using the Support User Access form.

After consenting to support access, authorized Veza personnel can log in to your tenant at the URL https://<your-organization.vezacloud.com>/api/private/support:login.

Enable Veza Support User

1. Log in as an administrator and go to System Settings.

1. Click Support User Access.

1. Assign appropriate team(s) and role(s). Click Next.

   For read-only investigation, assign the Operator role for the Root team. To enable the support user to make changes to your tenant, assign the Administrator role.

1. Click Next and tick the checkbox to consent to support access for an initial 12 hours. Click Grant Access to Veza Support to enable the user.

Granting access will notify the Veza support team. After access is granted, the page will show the user details and time remaining:

To add time in 24-hour increments, click the Extend Access button. Access can be granted for up to one week in this way.

Manage Support User Account

The user should now also be visible in the User Management table. This user will have the Support user type, and the Roles/Teams cannot be changed.

• Updating Roles/Teams for the support user requires disabling the user and re-granting access with the new Roles/Teams.

• Access extension can also be done from the Actions menu in the User Management table, as shown in the screenshot below.
• Any events produced by support user actions are logged with the support user email

• See the screenshot below to compare an API key creation Event for a normal user vs. a support user:
• When support access expires, the user is removed from all associated teams.

• When support access expires, any created API keys are deleted.

Overview

Virtual Private Veza is available for cloud-premises deployment within a customer-managed AWS Virtual Private Cloud (VPC) on an EKS cluster. This option enables a fully isolated installation where all access to Veza and collected data are within a customer's AWS account and cloud infrastructure.

Why Virtual Private Veza?

• Self-hosted in Customer Environment: All Veza services and operations are hosted within your own cloud infrastructure.

• Complete Control and Isolation: Operate Veza within a dedicated environment that ensures total isolation and control over your data and interactions.

• Local Access Graph and Metadata Management: Manage and analyze access and authorization metadata locally to ensure maximum performance and security.

• Compliance-Ready Deployment: Veza meets rigorous standards including SOC2 and ISO 27001, providing a robust security framework for enterprise needs.

• Customizable Implementation: Tailored setup and support from Veza ensure that your installation meets specific operational needs and compliance requirements.

Virtual Private Veza - Building Blocks

VPV Setup

Veza support staff will coordinate with the enterprise customer to train the customer’s staff to install, upgrade, configure, and maintain the Virtual Private Veza (VPV) installation.

Basic Infrastructure Setup

VPV runs on an EKS cluster and requires several custom IAM roles. The Veza staff will work with the customer to provide the current EKS requirements, the IAM policy documents, and the IAM trust policy documents for installation into the customer’s AWS account. The customer can then provide this infrastructure and the roles following their infrastructure deployment and management processes, i.e., Infrastructure-as-Code, security reviews, etc.

Deploy Virtual Private Veza

Once the infrastructure and IAM roles are ready, the Veza staff will work with the customer’s engineers to begin the deployment process within the AWS VPC and verify the functionality. The Veza staff will walk the customer’s engineers through the installation process so the customer’s staff can become proficient at installing, configuring, and upgrading the VPV environment.

Upgrades and maintenance

After the initial deployment, Veza staff will be accessible to the customer for support, including applying patches, bug fixes, and troubleshooting. Veza follows a weekly release cadence. By enabling customers to be self-sufficient with configuration changes and updates, they can update the environment on a cadence that fits their processes.

Learn More

For additional guidance on evaluating and implementing Virtual Private Veza (VPV) in your AWS VPC environments, please contact our sales engineering and customer success teams.

Virtual Private Veza (VPV) FAQ

Question: Does VPV “phone home?”

Answer: VPV does not send any data to Veza. The customer completely controls the data and all communications within their environment. Veza staff have no access to a VPV installation.

Question: What is the recommended Linux version? Are there specific EC2 tech specs? Is a separate AMI required?

Answer: There is no specific required version of Linux or Amazon Machine Image (AMI). We recommend using the latest version of , Red Hat Enterprise Linux, or Ubuntu.

Question: Where is the Veza ECR located?

Answer: The Veza ECR repository is in our production AWS account. We use an allowlist to ensure only Veza customer AWS accounts can access the Veza repository.

Question: Does Veza use AWS role ARNs or bespoke Kubernetes authentication?

Answer: The customer creates role ARNs with policies provided by Veza. The running services interact with AWS via an IAM role annotated on a Kubernetes service account. The customer controls Kubernetes authentication.

Question: Do we need to provision an EKS cluster to install Veza?

Answer: Yes. We want the customer to have full control over the infrastructure and be able to follow their processes for managing their AWS infrastructure.

Question: Are updates automatic?

Answer: Updates are only applied upon the deployment of a new version, which you can manage based on your requirements. For security and supportability reasons, we recommend updating at least once every four weeks.

Background

Veza can interpret an incoming SAML claim from an identity provider (IdP) to assign federated users to teams and roles based on group assignments in your IdP. If you do not want to create groups in your IdP with the exact naming syntax required by Veza, this document will help you map any group to the expected SAML Attribute Statements.

To enable SAML role assignments when users log in, an administrator will need to do one of the following:

• In Veza, configure to map groups in the incoming SAML claim to Veza roles. Configure the Okta to include a custom attribute that will contain the groups users belong to. See to configure a group attribute statement on the Veza app integration.

• In Okta, add a custom attribute for Veza app users that will contain their Veza role. Configure the application to include the custom attribute in a SAML groups attribute statement. Then, assign groups to the Veza application and specify the group role in the format {Team SSO Alias}:{role name}.

The instructions in this guide are for the second approach. Use them to map an Okta group (such as a "Veza Administrators" group) to a SAML Attribute Statement Value of Root:admin. Users in this group can log in to Veza with the admin role, without additional configuration of custom role mappings in Veza.

Define an AppUser Custom Attribute on the Veza SAML App

Go to Okta Directory > Profile Editor. Click on the Veza integration app user to edit it and click Add Attribute.

• Data Type: String Array

• Display Name: Veza Role

• Variable Name: role

• Description: Role for users in Veza

• Attribute Type: Group

• Group Priority: Combine values across groups (this is important for users with more than one role. Okta will send all Role Names to Veza rather than only the role mapped to the highest-priority group)

Add the SAML Attribute Statement on the Veza SAML App

Go to Okta Applications > Applications and click the Veza app integration to view details.

1. In the General tab, scroll down to SAML Settings, and click Edit.

2. In the Configure SAML tab, find the "Attribute Statements (optional)" section

3. Add the attribute statement: Name: groups Name format: Unspecified Value: appuser.role (assuming the AppUser variable name is role)

4. Save the changes.

By default, the SAML Attribute Statement on the Veza SAML App must be named groups. If you must use a name other than groups, you must specify the custom attribute name in the Veza SSO configuration.

Go to the Assignments Tab and assign your groups

1. Click Assign > Assign to groups and search for the group that will correspond to a Veza role (such as "Veza Administrators").

2. Click Assign and specify the Role attribute with the desired role. The value of the Attribute Statement should be {SSO Alias}:{role name}

Okta users in the chosen group are now assigned to the application with the Role (role) attribute value of Root:admin (or whatever you put in step 2):

Multi-Factor Authentication (MFA) enhances the security of your user account by requiring more than one form of verification when logging in, such as a password combined with time-sensitive credentials from an authenticator app.

Given the sensitive nature of Veza's data, your organization can mandate a second authentication factor for users. To enable MFA for a local Veza account, access your user profile.

If you sign in to Veza with Single Sign-On, you will not be able to enable MFA in Veza. Instead, you will use an authentication factor associated with your corporate identity provider account.

Configuring a third-party authenticator app

Set up MFA with an authenticator app such as Google Authenticator:

1. Click on your user name in the main navigation bar to access your user profile.

2. In the Two-Factor Authentication section, click Third-Party Authenticator App and click Configure.

3. Open your preferred authenticator app, and scan the QR code or manually enter the provided code.

4. Enter the code generated by your authenticator app.

5. Securely save the provided recovery codes for account backup.

6. Ensure that you have safely stored the recovery codes. Click Continue.

Recommended authenticator apps

Most mobile authenticator applications are compatible with Veza MFA. If you do not have an approved app, consider these:

Lost recovery codes

If you lose your recovery options, reach out to a Veza administrator within your organization. Administrators have the capability to reset your authenticator configuration. If your organization's sole administrator has lost access, contact Veza support for help.

All internal Veza operations are logged on the Administration > Events page, with a brief description and timestamp. You can filter by category and severity, select columns to display, and export your current filter view:

NOTE: Veza does not store events longer than 30 days.

To get more information for an event, click "Show Details" or on the status name under Severity.

Event Subscriptions

You can configure Event Subscriptions to get automated alerts for specific platform activity, without manually monitoring the Events page. Depending on your subscription settings, you can trigger email notifications whenever a certain severity, category, or type of event occurs.

For example, you can help ensure that Veza graph data remains fresh and represents the latest authorization state by configuring email alerts whenever an integration data source encounters errors, such as loss of connectivity or expired credentials.

Note: Event Subscriptions currently support only email notifications through Veza Actions. Webhook delivery options are not available at this time.

• Use to trigger webhook notifications based on query result changes.

• You can also use the and to programmatically retrieve and monitor system events and user activity for integration with external monitoring or SIEM platforms.

How Event Subscriptions Work

Administrators can configure periodic alerts on the Administration > Subscription Management page. For each configured subscription, Veza will send a summary of new events based on the subscription's frequency and filter criteria.

1. Subscription Criteria You can create a subscription by specifying the following parameters:

   • Event Category: Filter events by their high-level category (e.g., Integrations, Rule, Export).

   • Event Severity: Choose the severity level (e.g., Info, Warning, Error).

   • Event Type: Specify the type of event you want to track.

2. Evaluation Period Subscriptions are evaluated at regular intervals of 15 minutes (e.g., at 15, 30, 45, and 60-minute marks). During each evaluation, all events matching your subscription criteria are reviewed.

3. Alerts If any events match your subscription during an evaluation period, you will receive an email notification. The email includes:

   • Details of your subscription criteria.

   • The total number of events that occurred since the last evaluation.

Enabling Event Subscriptions

Use the Subscriptions tab to review, edit, and delete saved subscriptions. To create a subscription:

1. In Veza, open Administration > Event Subscriptions.

2. Click Create Subscription.

3. On the Details tab, enter a name and description for the subscription, and choose the evaluation time interval.

4. On the Conditions tab, choose from event types, severity levels, and categories to define the filter.

5. On the Actions > Send Alert tab, select an email destination from configured Veza Actions, or click "Create Veza Action" to add a new email destination.

6. Click Create to save the subscription.

Alert Details

Use the Event Subscriptions > Alert Details tab to get a summary of subscription activity, including the trigger time and number of events included in each alert. By default, this view shows all activity during the chosen time range.

To review all activity for a specific subscription:

1. Hover over the subscription on the Subscriptions tab.

2. Click the View Alerts icon to see its specific alerts.

This guide will help you add an Okta app integration to enable single sign-on (SSO) using OpenID Connect (OIDC) for Veza, and manage teams and roles within your identity provider.

To enable SSO, you will need access to the Okta admin portal and have the administrator role in Veza.

Step 1: Create an Okta app integration

Log in to your Okta administration portal (for example, https://oktadomain-admin.okta.com).

Open Applications > Applications and click Create App Integration.

Select OIDC for the Sign-in method, choose Web Application for the Application type, and then click Next:

Give the app a name and click Next:

Step 2: Configure the Sign-in redirect URIs

To configure Sign-in redirect you will need the Veza Redirect URL and Logout URL.

You can retrieve these by navigating to Veza Administration > Sign-in Settings, clicking Configure under Enable OpenID Connect, and copying the values at the top of the dialog box.

In the Okta App:

1. Enter the Redirect URL in the Sign-in redirect URIs section

2. Enter the Logout URL in the Logout redirect URIs section

Step 3 (Optional): Configure RP Initiated Logout / Single Logout (SLO)

RP Initiated Logout is a feature that allows the relying party (RP), in this case Veza, to initiate the logout process. When enabled, users can log out from Veza and be automatically logged out from Okta as well.

In Veza you need to enable RP Initiated Logout in the SSO configuration:

1. Navigate to Administration > Sign-in Settings, and click Configure under Enable OpenID Connect

2. Toggle Enable RP Initiated Logout to enabled

3. Copy the displayed Single logout URL

In the Okta App Logout section:

1. Select the User logs out of other logout-initiating apps or Okta checkbox

2. Select the Include user session details checkbox

Step 4: Save the Okta app configuration

Click on the Save button to save the Okta app configuration. Leave the tab open.

Step 5: Configure and enable Veza single sign-on

1. In Okta copy the Client ID from the Client Credentials section

2. In Veza navigate to Administration > Sign-in Settings, and click Configure under Enable OpenID Connect

3. Enter the Idp Issuer URL (e.g. https://oktadomain.okta.com)

4. Paste the Client ID from Okta into the Client ID field

5. Select Private Key JWT as the Auth Method method

6. Copy the Public Keys URL shown below

7. In Okta click Edit on the Client Credentials section

8. Select Public key / Private key as the Client authentication method

9. Enable the Require PKCE as additional verification checkbox

10. Paste the Public Keys URL from Veza into the Url field under the Public Keys section

11. Click Save to save the configuration in Okta

12. Add optional to assign users to Veza teams and roles based on Okta group assignments.

13. Click Confirm to finalize the configuration in Veza

Step 6: Save and enable the connection

Click save on the configuration page to return to Sign-in Settings, and toggle the option to enable SSO under Enable OpenID Connect. Visitors will now have the choice to Login with SSO, which will redirect to Okta for authentication.

Teams overview

On Veza, team assignments can restrict the authorization data a user can see, based on the integrations scoped to the team. After an administrator has created a custom team and defined the integrations its members can access, they can add users to the team and set an operator or viewer role on the Veza Team Management page.

• The Root team allows for full visibility of all graph data and access to the Operator, Administrator and 'Access Reviewer roles.

• Non-Root teams support a read-only Viewer role, and a limited Operator role.

• Users must have an administrator or operator Root team role to access Veza Access Reviews, Rules, and Administration features.

• Non-root team members can view events and integrations in the team scope, but not change configurations.

• Teams enable read-only, limited-scope API Keys.

• Each team has a unique copy of built-in reports, queries, and saved searches.

When creating a team, administrators specify the allowed graph data sources from a list of all provider integrations. The team's scope might include a single cloud provider account, identity provider domain, or SQL database, or grant access to many different integrations.

Create a team

To add a team and define its scope, go to Administration > Team Management.

1. Click Add Team

2. Add a team name and description

3. Select the integrations that will be visible to the team from the list of Providers scoped to the Team

4. Click Create Team

To optimize the user experience in non-root teams, consider if users will need access to related identity or resource entities from another integrated provider. This might include Single Sign-On users from an external IdP, or roles and groups from another cloud platform.

Add members to a team

You can add or remove team members from the Team Management page, or when creating a user from the Users page. You will need to create a team before you can add users.

1. Find the team on the list of Teams

2. Click on the team to open the team details

3. Click Add Users

4. Add a user by selecting one from the dropdown menu

5. Pick a role for the user

6. Click Confirm

Users on non-root teams can only have the viewer or operator role. Other roles are currently restricted to the root team.

Change the active team

When browsing the Veza platform, users on non-root teams can only view entities and Veza features allowed by the user's role and the team's scope. Users can change the active team under their Profile to view graph results for different teams.

To change the active team:

1. Click your username on the main Veza navigation menu

2. On the Your Profile page, find the Teams section

3. Pick an active team from the dropdown menu

If entities are not allowed for the user's team but are critical in describing the permissions path of in-scope results, redacted entities appear in their place.

Users assigned to non-root teams can only view Queries associated with allowed Integrations for their team.

For users assigned to more than one team, the current level of access depends on the team the user has actively enabled. Users can change their current active team on their Profile page.

Veza administrators can configure ServiceNow as a destination for Workflow events, to create tickets when rows are rejected by reviewers. Using the information from Veza, another team can follow up on a decision, and stakeholders can get additional visibility into certification progress.

Prerequisites and Capabilities

• You will need administrator access to your ServiceNow instance to create a service account. This account requires permission to create incidents. The integration will not make any other changes or delete tickets.

• Any table (including custom tables) can be set as the ticket destination

• The Veza-ServiceNow Veza Action is maintained for the current ServiceNow version (San Diego). However, it should be compatible with earlier versions if the following API calls are available:

  • GET /api/now/table/{table_name}/short_description=xxx

  • POST /api/now/table/{table_name}

• The Veza Action is not aware of . You may want to establish your own internal logic for assigning newly-created issues in the table.

Create a ServiceNow API user

Before adding the Veza Action to Veza, you will need to connect to ServiceNow to create an API User (service account) to create the ticket as

1. Navigate to https://<your_instance>.service-now.com and log in with an account that has the user_admin role.

2. In the left navigation pane, expand User Management and click Users.

3. At the top of the main pane, click New.

4. Ensure that Web service access only is checked to only allow API calls for the account, and prevent UI access.

5. Check Internal Integration User to mark the user as a service account.

6. Make note of the user ID and password values.

7. To allow the service account to create incidents, open the user roles tab, click edit and find the sn_incident_write role collection. Add it to the roles list and click Save.

For more information, see .

Add a ServiceNow Veza Action in Veza

1. Browse to Integrations > Veza Actions > Add Veza Action

2. Click ServiceNow and click Next.

3. Fill out the required fields:

Click Next to test and create the Veza Action.

Setting ServiceNow as an alert destination

Any ServiceNow Veza Action you create can be used within Access Reviews to create tickets when access is rejected by a reviewer. To add ServiceNow alerts to an existing review configuration:

1. Find the configuration on the Access Reviews > Configurations page.

2. Click on a configuration name to view details.

3. Click Edit to open the configuration builder.

4. Scroll down to the Veza Actions section.

5. Check the Reject Row box and choose the ServiceNow Veza Action from the dropdown menu.

6. Click Update Configuration to save the changes.

Administrators and operators can add ServiceNow actions for an individual access review:

1. On the Access Reviews > Reviews page, click a review name to open it.

2. Click the icon to the right of the sign-off actions to open the review details sidebar.

3. In the sidebar, click Veza Actions.
4. In the Veza Actions modal, check the Reject Row box and use the dropdown menu to pick an action.

For access reviews with a ServiceNow Veza Action enabled, users can show or hide additional columns with Veza Action status details for signed-off and rejected rows:

• Notification Details, which you can click to view the ticket ID

• Notification Status, which can be PENDING, SUCCESS, or FAILED

See for more details.

Overview

Veza supports SAML and OIDC-based Single Sign-On (SSO) for seamless authentication with third-party Identity Providers (IdPs) like Okta and Azure AD.

Platform features include session idle timeout, API key-based programmatic access, SCIM provisioning for external user management, and IdP-managed role assignments.

Local accounts and multi-factor authentication are also supported for added security.

General Settings

Session Idle Timeout

This setting defines the maximum idle time before a user is automatically logged out of Veza. The default value is 30 minutes, but you can adjust it to meet your organization's security requirements.

This applies to all users, regardless of their authentication method (SSO or local accounts).

SSO

SSO configures SAML and OIDC SSO mechanisms. The following configuration features are available for both the SAML and OIDC:

1. Attribute Mapping: Map user attributes from the incoming SAML assertion or OIDC claim to corresponding attributes within Veza.

   • Available in SAML and OIDC configuration pages.

2. Role Mapping: Map groups from the incoming SAML assertion or OIDC claim to Veza teams and roles.

   • Available in SAML and OIDC configuration pages.

3. SSO Redirect: When SSO is active, users attempting to log in to Veza are automatically redirected to their Identity Provider (IdP) login page.

4. IdP-Managed Role Assignments: Push group assignments from your IdP to Veza.

SAML

Veza supports SAML, the XML-based standard for single-sign-on. When enabled, users can log in to Veza using a third-party Identity Provider, such as OneLogin, Okta, Azure AD, or a custom provider.

After registering Veza as a SAML service provider (SP) with your IdP and configuring and enabling from Administration > Sign-in Settings, you will be able to assign access to Veza directly from the IdP. The login page will offer the option to "Login with SSO" and redirect users to your IdP for authentication.

Our SAML guide has instructions to configure SAML as your SSO provider.

We offer more detailed instructions for configuring SAML SSO with Okta and Microsoft Entra (Azure AD).

OIDC

Our OIDC guide has instructions to configure OIDC as your SSO provider.

We have a detailed guide for configuring OIDC SSO with Okta.

SSO Redirect

When SSO is enabled, users will be redirected to the IdP login page when they attempt to log in to Veza. If you want to disable this behavior, you can do so by going to Settings > Sign-in Settings and toggling the SSO Redirect option.

Enabling or disabling IdP-managed role assignments

Depending on Veza system settings, group assignments in your IdP can take precedence over changes to teams or roles made by an administrator on the Veza User Management page.

To change this setting, find the Identity Provider Managed Roles option under Veza Sign-in Settings:

1. Go to Veza Settings > Sign In Settings and find Identity Provider Managed Roles.

   • When this option is disabled, any assignments based on IdP roles only apply the first time a user logs in.

   • When enabled, user management within Veza is prevented, and your identity provider is the single source of truth for Veza teams and roles.

2. Click the toggle to enable or disable the setting.

Global IdP Settings

Single Sign-On for Access Reviewers

Using Single Sign-On in combination with a Global Workflows Identity Provider, Workflow certification reviewers can be auto-assigned using Identity Provider metadata and log in to Veza using SSO to act on their assigned certifications. As the default role for SSO users is access_reviewer, this will enable limited access for all users in your organization, without exposing other Veza features or certifications that the user is not involved in.

API Keys

API Keys section contains settings for programmatic access.

Enable API Keys

The Enable API Keys setting allows the creation and use of personal and team API keys.

Personal API keys are associated with a specific user and can be used to access the Veza API on behalf of that user. Team API keys are associated with a specific team principal.

Local

Local section contains settings for local accounts.

Enable Local Accounts

The Enable Local Accounts setting allows the creation and use of accounts authenticated with an email address and password.

Disabling this setting will restrict login options to only Single Sign-On (SSO). Associated personal API keys are also disabled.

Enabling Multi-Factor Authentication

You can enable 2-factor authentication for local accounts under Administration > Sign-in Settings. When enabled, ALL LOCAL ACCOUNTS will be prompted when they first log in to register an authenticator app by scanning a QR code and entering the one-time code (Google Authenticator for Android or iOS).

Overview

Veza supports SAML, the XML-based standard for single-sign-on. When enabled, users can log in to Veza using a third-party Identity Provider, such as OneLogin, Okta, Azure AD, or a custom provider.

After registering Veza as a SAML service provider (SP) with your IdP and configuring the connection from Administration > Sign-in Settings, you can assign access to Veza directly from the IdP. The login page will offer the option to "Login with SSO" and redirect users to your IdP for authentication.

SSO flows can be:

• Service Provider-initiated: Users log in at the Veza home page (yourorg.vezacloud.com)

• Identity Provider-Initiated: Users log in to Veza via their IDP app dashboard (such as your organization's Okta Portal)

For a step-by-step guide to configure SAML for Okta, which may be adapted for other providers, please see SSO For Okta. Instructions are also available for Microsoft Entra (Azure AD).

For advanced user lifecycle management, Veza supports SCIM Provisioning in addition to SAML. When SCIM provisioning is enabled, it becomes the authoritative source for user profile updates, and SAML Just-in-Time (JIT) provisioning is automatically disabled to prevent conflicts.

Enabling SAML

You can download service provider (SP) metadata from Veza to reference when configuring the connection in your Identity Provider. When configuring your IdP, you should retrieve an X.509 certificate and the Single Sign-On URL, which Veza will need to enable SSO.

The following order of operations is recommended:

1. Connect to your identity provider to get the required IdP SAML metadata. You will need the X.509 certificate, Sign-In URL, and SAML request protocol binding. You will also need the signing request algorithm and digest, unless your IdP doesn't support signed requests.

2. Log in to Veza using your administrator username and password. Navigate to Administration > Sign-in Settings, and choose to enable SAML. Click "Configure."

3. Complete the required fields, save the configuration, and download the service provider (SP) metadata.

4. Log in to your Identity Provider (IdP), and use the SP metadata from Veza to register a new SAML service provider.

5. Enable the SSO connection from Veza Administration > Sign-in Settings panel

See Veza Configuration and Identity Provider Configuration below for details on the information you will need to provide at each step.

Configure Veza for Single Sign-On

1. Create a new SAML connection

You can download SP metadata from Veza, which contains information you'll need to set up SSO within your IdP. First, you'll need to save a new SAML configuration from Administration > Sign-in Settings. You will need to provide the following information:

2. Enable Identity Provider-initiated Single Sign On (optional)

When enabled, authorized IdP users accessing Veza via the IdP app portal will be logged in automatically.

3. Download the service provider metadata

Once you have saved the SSO configuration, you can download the service provider metadata for Veza in SAML format. This information can be imported into most identity providers or used for reference if you need to input the values manually.

4. Enable or Disable an SSO connection

Enable the SAML connection from the Authentication panel after registering Veza with your Identity Provider (see below). Once enabled, visitors to your Veza instance can log in with a username/password or authenticate via the IdP sign-in URL.

Configure Identity Provider for Single Sign-On

The exact steps to create a new integration vary depending on your IdP. Typically, you will need to register a new application or service provider and specify the Single Sign-On URL assigned for your Veza instance (responsible for handling SAML assertions).

For additional resources on adding a new SAML provider with common IdPs, you can refer to the standard documentation for AzureAD, Okta, and Google.

Managing SAML users

After configuring a SAML identity provider, you can manage Veza users from your Identity Provider by assigning an IdP user or group to the Veza application. The first time a user logs in to Veza with SSO, a local Veza user account is created and shown on the Administration > User Management page.

Notes:

• IdP user passwords cannot be changed from the Veza UI

• No account creation email will be sent until the user first logs in. You may want to inform users that they can now access Veza using their IdP credentials.

• You should retain a Veza admin account configured for password authentication to use if the SSO connection is disrupted.

Attribute Mapping

When configuring SAML, you can map user attributes from your IdP to Veza. The following attributes are supported:

See Attribute Mapping for details on how to configure attribute mapping for SSO users.

Teams (Role Assignments) with Single Sign-On

Role mapping allows you to assign teams and roles based on a user's groups during login.

See Role Mapping for details on how to configure teams and roles for SSO users.

If your organization uses Entra ID (formerly Microsoft Azure AD) for single sign-on, you can manage access to Veza through a pre-built integration available in the Microsoft Entra application gallery.

After configuring the Veza gallery app, you can assign users and groups, and use Entra ID to manage their teams and roles within Veza.

Requirements

• A Microsoft Entra subscription

• Permission to create enterprise applications in Entra (such as the Application Administrator role)

• Administrator access to Veza to retrieve the SAML configuration values.

• To enable role mappings for Entra ID groups, Team and Role Mapping (Early Access) must be enabled for your Veza platform.

Configure Single Sign-On

To install Veza as an official gallery application, follow the instructions provided in the Microsoft Entra SSO integration with Veza tutorial.

Role Mapping for Entra ID

Configure role mappings in Veza to assign teams and roles based on metadata in the SAML claim when users log in.

To enable group claims for the Veza SAML app, follow the instructions in Add group claims to tokens for SAML applications using SSO configuration. You will need to:

1. Edit the Veza gallery application to add a group claim.

2. Choose to return Groups assigned to the application with source attribute "Group ID."
3. In Entra, view Users and groups to list the groups assigned to the Veza application:
4. For each group, view the group in Entra and copy its object ID to use in Veza:
5. In Veza, edit the SAML configuration to add a mapping for each group:

   • Attribute: For Entra ID, set this to http://schemas.microsoft.com/ws/2008/06/identity/claims/groups.

   • Team Role Mapping: Enable to map Entra ID groups to Veza teams and roles.

   • Mapping: For Entra ID, the group Object ID to map to the role/team.

   • Role / Team: The root team role or team-role assignment mapped to a group ID.

Important: The role mapping must use the group's ObjectID attribute (not a friendly name or sAMAAccountName). To retrieve this value for role mapping configurations:

Open an individual group to view details:

Or check the IDs on the Groups > All Groups page:

See Role Mapping for Single Sign-On for more details.

Overview

Veza integrations collect and analyze sensitive information about your organization's security posture, including identity relationships, permission assignments, resource configurations, and cross-system access patterns and risks.

This metadata provides valuable insights for legitimate users but can pose a potential attack map if compromised. Implementing appropriate security controls before adding integrations and inviting users is fundamental to protecting your Veza tenant and organization.

The steps in this document will help you get started with a security-first approach to Veza access policies by:

• Enabling Single Sign-On (SSO) for your SAML or OIDC identity provider

• Disabling local accounts (Recommended)

• Requiring MFA for local users (if enabled)

For more information about how Veza protects customer data, see the .

Prerequisites

• Access to your Veza tenant

• Temporary administrative credentials provided by your Veza success team

• Access to your Identity provider (IdP) for SSO configuration

• Permission to modify IdP authentication settings in your organization

Security Configuration

1. Configure Single Sign-On (SSO)

Integrate Veza with your identity provider to enable centralized authentication and access management. Expected time: 1-2 hours.

1. Open Administration > Sign-in Settings

2. In the SSO section, click Configure and follow the configuration guide for your identity provider:

3. Test the SSO configuration with a non-admin user

4. Verify that user attributes and groups are mapping as expected

See for details about configuring SSO and default team and role assignments for federated users.

2. Enable Multi-Factor Authentication (MFA)

If maintaining local accounts, you should require users to enable a second authentication factor for enhanced security. Expected time: 10 minutes.

1. Go to Administration > Sign-in Settings

2. In the Local section, click Require MFA for all local users

3. Ensure all existing local accounts have configured MFA

4. Verify MFA enforcement by logging in as a local user

See for details on enabling authentication factors for a local user.

3. Local Account Management

Choose one of the following approaches based on your security requirements:

Option A: Disable Local Accounts (Recommended)

Once SSO is configured and verified:

1. Navigate to Administration > Sign-in Settings

2. Find the Local section

3. Disable the Enable Local Accounts option

Use the Administration > User Management page to review existing local accounts. Migrate administrative access to SSO-based accounts, and disable or remove unnecessary local accounts.

Option B: Maintain Local Accounts with Enhanced Security

If local accounts must be enabled:

1. Require MFA as described above

2. Audit local account using the Events page or

3. Document the business justification for the maintained local accounts

Verification Steps

After completing these security configurations, verify all settings before proceeding:

1. Confirm that SSO authentication functions for all user groups, based on configured team and role mappings

2. Verify that local user access is disabled

3. Verify MFA enforcement for local accounts (if enabled)

4. Review the security settings, users, and teams in the Veza Administration section

5. Document configurations and verification results for future audits and reviews

Learning More

With access to Veza secured, you can continue to:

• Enable if required for integration connectivity

• Learn more about other capabilities

• Configure and for Veza users

• See the product documentation to learn more about Veza features:

Overview

When using Single Sign-On, Veza can map your IdP groups to Veza teams and role assignments for users logging in via SAML or OIDC. This allows you to control access to Veza based on group membership in your Identity Provider (IdP).

To access these settings:

1. Go to Veza Settings > Sign-In Settings.

2. Find the appropriate SSO provider (SAML or OIDC), click Configure.

3. Scroll to the Role Mapping section.

Mapping Table

Use the role mapping table to assign IdP groups to teams and role assignments in Veza.

• IdP Group: The group from your IdP. This may be a group name or UUID, depending on your IdP.

• Team: The Veza team to which the group or role ID will be mapped.

• Role: The Veza role to which the group or role ID will be mapped.

• Actions: The actions you can take on the mapping. You can add or delete mappings. A single value can have multiple mappings.

Each mapping entry in the table consists of 1) an IdP group and 2) 1-N Veza team-role assignments. Each row is a Veza team-role pair. An arrow in the IdP Group column indicates that the row is a continuation of a previous row and indicates that the same IdP group has multiple team-role assignments. You may have any number of team-role pairs for a single IdP group.

Default Team and Role Assignments

The Default IdP Group is a mandatory special mapping for assigning default teams and roles to users authenticating via SSO. It is used when:

1. The user profile lacks group information.

2. Veza cannot map the provided group(s) to a team-role assignment.

Adding a Default Mapping

1. Go to Veza Settings > Sign-In Settings.

2. Find the appropriate SSO provider (SAML or OIDC), click Configure, then scroll down to the Role Mapping section.

3. Find Default mapping.

4. Pick a default team (Root or a custom team).

5. Pick a default role (such as Admin, Operator, Viewer, or Reviewer).

6. Optionally, click the "+" icon in the Actions column to add more default teams and roles.

7. Click Confirm to save the changes.

SSO users are assigned the default teams and roles when no other assignment is provided. If the SAML claim from the identity provider contains team-role assignments, those will be used instead.

Custom Team and Role Assignments

You can create custom mappings for your IdP groups to assign users to specific teams and roles. These mappings link Veza team-role combinations to your Identity Provider groups.

Adding and Removing Mappings

1. Go to Veza Settings > Sign-In Settings.

2. Find the appropriate SSO provider (SAML or OIDC), click Configure, then scroll to the Role Mapping section.

   • Add mappings by entering the group or role ID that will map to Role and Team assignments.

   • Remove mappings by clicking the trash can icon in the actions column.

   • To add more than one mapping for a value, click the "+" icon.

3. Click Confirm to save the changes.

Troubleshooting Role Assignments

• Verify your Identity Provider includes the claim in the SAML token. This is typically configurable on a per-application basis, for example:

• Confirm that mappings are correct on the Configure SSO page. Attribute names and values are case-sensitive.

You can enable webhooks for Veza to publish event notifications to external applications. When a destination URL is provided, Veza will push a JSON payload containing alert details whenever the rule results change. Any entities added or removed since the last evaluation are included in the payload.

Webhooks can enable automated processes such as updating an issue tracker, creating a service desk ticket, or sending email or SMS notifications when Veza pushes an alert.

Webhooks can trigger remediation actions when a row is approved or rejected. See for examples of the unique payloads based on the review due date, or when rows are signed off.

Domain Filtering for Veza Actions: Administrators can configure a list of approved domains for email and webhook Veza Actions on the System Settings page. Messages are not sent to unapproved domains when this option is enabled.

Configuring a new webhook

Navigate to Integrations > Veza Actions > Create Veza Action. Enter the required details:

• A Name to identify the webhook

• The destination URL of the application expecting the payload

• Optionally, configure authentication by selecting the appropriate authentication method:

  • Basic Authentication: Select "Basic" from the authentication type dropdown and enter a username and password

  • Token Authentication: Select "Token" from the authentication type dropdown and provide a token value

Adding a webhook to a rule

Webhooks can be attached to rules by opening the , accessed from the Access Intelligence > Rules & Alerts page, or by selecting an assessment from Access Search > Saved Queries.

• From Rules, edit an existing rule or create a new one to open the rule builder

• From the Saved Queries list, choose "Create a Rule" from the actions list

• On the Edit Rule screen, select Deliver Alert via Webhook/Email and set an existing webhook

Using the Webhooks panel

You can view, create, and edit webhooks on the Integrations > Veza Actions page. For each rule, you can review the:

• Name - provided when the webhook was created

• Rules - any connected rules will be listed. If none are associated, the option to connect a rule will display instead

• Actions - Edit, test, or delete the webhook

Testing a webhook

Click "test" on the webhook builder or configuration screen to validate that a URL has been successfully configured. A sample request will be sent to the destination URL, and a success notification will appear if Veza is able to POST a test notification to the endpoint. You should verify from the endpoint that the payload was delivered as expected.

You can also test the webhook by editing a rule and saving changes. Queries are evaluated when a rule is updated.

Webhook payloads

Alerts

Sample alert:

Authentication Headers

Veza supports two authentication methods for webhooks:

Basic Authentication

When configuring a webhook with Basic Authentication, provide both a username and password. Veza will include a Basic Authentication header with the Base64-encoded credentials in the format username:password:

In the example above, dXNlcjoxMjM= is the Base64 encoding of user:123.

Additionally, when using Basic Authentication, the credentials will also be included as separate header fields:

Token Authentication

When configuring a webhook with Token Authentication, provide a token value. Veza will include it directly in the Authorization header:

Where 123 is the token value you configured.

This guide will help you add an Okta app integration to enable single sign-on (SSO) for Veza, and manage teams and roles within your identity provider.

To enable SSO, you will need access to the Okta admin portal and have the administrator role in Veza.

Step 1: Create an Okta app integration

Log in to your Okta administration portal (for example, https://oktadomain-admin.okta.com).

Open Applications > Applications and click Create App Integration.

Enable SAML 2.0 for the protocol and click Next:

Give the app a name and click Next:

Step 2: Configure the app

To configure an Okta app you will need the Veza Single Sign On URL and Audience URI (SP Entity ID).

You can retrieve these by navigating to Veza Administration > Sign-in Settings, clicking Configure to enable SSO, and copying the values at the top of the wizard.

• SSO URL: The Veza Single Sign on URL (ACS), e.g. https://your-org.vezacloud.com/auth/saml/acs. This is the Location= value in the downloaded SP Metadata.

• SP Entity ID: The Veza Audience URI (Entity ID), for example https://your-org.vezacloud.com/auth/saml/metadata. This is the entityID= value in the downloaded SP Metadata URL.

In the App SAML Settings section, enter the Veza SSO URL and SP Entity ID.

• For Name ID format, pick EmailAddress

• For Application Username, pick "Okta Username"

These settings enable Veza to correctly identify and authenticate managers who are auto-assigned to Access Reviews.

Note: If you want to enable Single Logout, you will need to return to this page and click on Show Advanced Settings after you have saved the configuration in Veza. You will need the populate the SLO URL, the SP Issuer (same as the SP Entity ID), and the SP Certificate, all available in the SP metadata.

Click Next to finish setting up the application. On the final step, click Okta customer and This is an internal app. Click Finish.

After creating the application, you need to configure additional settings on the General tab:

1. Return to the app's configuration page and select the General tab

2. Click Edit if the settings are not already in edit mode

3. Find the Default RelayState field in the application settings

4. Enter a value of / (a single forward slash) to redirect users to the Veza homepage

5. Click Save

Important: The Default RelayState parameter is required for IdP-initiated SSO to function correctly. Without this setting, users clicking the Veza tile in the Okta dashboard may encounter errors or failed redirects, even if all other configuration is correct.

Step 3: Get identity provider metadata for the Okta App

On the next screen, click View Setup Instructions:

Copy the “Identity Provider Single Sign-On URL” and "Identity Provider Issuer" values, and download the certificate “X.509 Certificate” which you will need when configuring Veza:

Step 4 (Optional): Enable identity provider managed roles

Veza can use group information from Okta to assign teams and roles when users first log in. Teams are assigned based on mappings in Sign-in Settings. To enable this, you can configure the Okta app to transmit a list of Okta groups the application user belongs to.

1. Click Show Advanced Settings for the Okta app.

2. Scroll to Group Attribute Statements (optional).

3. Enter the attribute name for group values.

4. Use Filter settings to specify Okta groups to include in the SAML claim.

Next, map these groups to teams and roles in Veza:

1. Go to Veza Sign-in Settings > SSO > Configure SAML.

2. Scroll down to the Role Mapping section.

3. For SAML Attribute, enter groups.

4. Click "Add" to create a mapping.

5. Type in the name of the Okta group. Use the dropdown menus to pick a team and role to assign.

6. Optionally, assign more team and role pairs for the group by clicking the "+" icon in the Actions column.

7. Repeat this process to add a mapping for each Okta group that will have a team and role in Veza.

Step 5: Configure and enable Veza single sign-on

1. Click the toggle to enable SSO under Administration > Sign-in Settings.

2. Click to configure SSO. Enter the Okta sign-in URL and upload the signing certificate.

3. Enable RSA-SHA-256 and SHA-256 as the Sign Request Algorithm and Digest. Enable HTTP-POST as the Protocol Binding.

4. The icon chosen with the Button Logo URL appears on the Veza login page.

5. Tick the box Enable IDP Initiated login. When enabled, app users can open Veza from their Okta dashboard without logging in. Make sure you've configured the Default RelayState as described in Step 2.

6. For Issuer ID, use the Identity Provider Issuer value from Okta, e.g. http://www.okta.com/ackfl76549mHKsk9q5d7

7. Add optional role mappings to assign users to Veza teams and roles based on Okta group assignments.

Step 6: Save and enable the connection

Click save on the configuration page to return to Sign-in Settings, and toggle the option to enable SSO. Visitors will now have the choice to Continue with SAML SSO, which will redirect to Okta for authentication.

You can add additional users from the Administration > User Management page. The Users list will show all system users and local accounts provisioned for users who have logged in with single sign-on. Veza administrators can download the full access log in CSV format by clicking the Export Audit Logs button at the top of the screen.

• Adding local users

• Changing and assigning user roles

• Single sign-on and default roles

• Passwords and login

• Roles

  • Root team roles

Adding local users

To add a local user and assign a team and role:

1. Click Add User.

2. Enter a user name and email.

3. Pick a team and roles:

   • Assign the root team to grant users access to all integrated providers based on their role. Use the selector to assign more than one role.

   • Assign custom teams to limit user access based on the integrations in the team scope.

   • Click + Add Another Team to assign more teams, up to a soft limit of 15.

4. Click Create User to save the changes.

Changing and assigning user roles

To change or add roles for local users:

1. Go to Administration > Team Management and click the team name.

2. Click Change Roles for the chosen user.

• Users on Root teams can have the administrator, access reviewer, or operator role.

• Users on non-root teams can only have the operator or viewer role.

• Early Access: Root team members can have the watcher read-only operator role, and the re-assigner role with limited capability to manage reviewers for Access Reviews.

Single sign-on and default roles

To enable Single Sign-On for your users, you must configure a compatible identity provider. After enabling SSO, Veza will create a local account after a visitor has authenticated with their IdP for the first time. This allows you to assign workflow reviewers within your organization by email without creating an account beforehand.

Your SSO configuration can define a default role for federated identities. Veza recommends validating this behavior and contacting the Veza customer success team to change it if desired. By default, Veza will assign the Reviewers role to SSO users.

If you have configured the IdP used for Single Sign-On as a Veza integration, you can change the Global Workflows IdP configuration to enable reviewer suggestions by attributes such as user email and manager id.

For organizations requiring automated user lifecycle management, Veza also supports SCIM Provisioning integration with compatible identity providers such as Okta and Microsoft Entra ID. When enabled, this allows fully automated user provisioning, updates, and deprovisioning directly from your IdP.

Passwords and login

Password requirements include:

• A minimum of 8 characters.

• At least 5 unique characters.

• At least one upper case letter, lower case letter, or symbol.

Additionally, Veza prohibits the reuse of your last 8 passwords.

If users have issues (such as a 401 error) when attempting to log in after a password change, they should clear their browser cookies before signing in again.

Roles

Role assignments define a user's permissions within Veza. Administrators can apply roles when creating a user, and change them from the User Management page. Possible roles are:

You can change the role of an SSO user after their first login. Most users will use the Operator role depending on their everyday tasks. Note that the Reviewer role only permits access to the Access Reviews feature, and only for reviews where the user is directly assigned.

Root team roles

• * Users with the operator role can only view their own saved searches.

• ** Users with the access reviewer role can only view and continue their assigned Access Reviews.

• *** Users with the access reviewer role can only see relationships and entity properties (such as tags) for their assigned results. They cannot use Search features such as Graph or the Query Builder.