Configuring the Veza integration for Okta.
Veza integrates with Okta to gather individual user metadata, applications, groups, and domains. After synchronizing with Okta, Veza shows the relationships connecting Okta identities and the external data sources and services they access (such as Snowflake databases, SQL tables, or AWS S3 buckets).
You can use Okta properties such as country, department, or login date to filter queries and define access reviewers for Okta users
Veza can establish a connection to Okta using OAuth 2.0 application credentials or user API keys. OAuth is recommended to provide greater control over application permissions, but you can use API keys for testing or non-production environments.
Log in to Okta to create a new app integration, generate keys, and assign scopes and roles:
The OAuth App requires a super admin or read-only admin role in your Okta organization. If you encounter a permissions error at step 5, the feature is not enabled. Go to Okta Settings > Features and enable the Assign admin roles to public client app option.
Go to Applications after logging into your Okta account. Record your Okta organization's URL, omitting https://
Create a new app:
Click on Create App Integration.
Choose API Services as the integration type.
Configure the Application:
Assign a descriptive name to your application.
In the app configuration section, edit the client credentials:
Copy the Client ID.
For Client Authentication, enable Public key/Private key.
In General Settings, ensure the option Require Demonstrating Proof of Possession (DPoP) is disabled.
Under Public Keys, add a key and copy the PEM value (starting with -----BEGIN PRIVATE KEY-----). Save this key and copy the Key ID (KID). Save your changes.
Convert the PEM private key to an RSA private key using OpenSSL: Run openssl rsa -in ~/okta_generated.key -out okta_updated.key -traditional in your terminal.
Assign scopes: In the Okta API Scopes section, find and grant the application scopes:
okta.users.read
okta.groups.read
okta.apps.read
okta.roles.read
okta.logs.read
okta.userTypes.read
On the Admin Roles tab, click Edit Assignments > Add Assignment. Assign the Read-only Administrator role and save the changes.
(Optional) To gather and show metadata for Okta Admin Roles, the Veza app needs the Super Administrator role.
The application scopes granted above will restrict the integration to read-only capabilities. For a full visualization of access in Okta, Veza recommends granting a super admin role if possible.
Create a user for Veza and assign an administrator role:
Open Directory > People and click Add Person.
Enter user details for the profile (such as VezaIntegration). Click Save.
Open Security > Administrators and click Add Administrator.
In the Grant Administrator Role To field, enter the name of the Veza user.
Pick Read-Only Administrator for the assigned role.
Save the changes.
Gathering metadata for Administrator Roles requires that the integration has Okta superuser permissions. To optionally do so you must assign the
super adminrole instead ofread-only admin.
Get an access token for the Okta user
Sign in to your Okta domain with the read-only admin username and password.
Go to Security > API using the admin console menu. Open the Tokens tab.
Click Create Token.
Give it a name and click Create Token.
Save the token value, which will only appear once.
Go to the Veza Integrations page to enable the Okta integration:
Click Integrations on the main navigation.
Click Add Integration > Okta*.
Enter your organization's Okta Domain to authenticate with.
Pick the Credential Type: API token or OAuth.
For OAuth authentication, enter your client ID and private key ID. Upload the RSA private key.
For API token authentication, enter the token generated for your Okta user.
Click Create Integration to save the configuration.
To prevent large Okta environments from causing integration pipeline delays, Veza recommends enabling audit log extraction as described in the next section.
Veza can parse Okta system logs to extract activity metadata. This enables two key capabilities:
Incremental Extraction for the Okta integration: Enabling audit logs allows updates to Authorization Graph metadata only for entities that have changed since the last snapshot. This reduces the time needed to gather users, groups, apps, and roles during each sync. Administrators should enable this feature post-Okta integration setup to improve extraction speed and minimize traffic to Okta API endpoints.
To enable audit logs for an Okta integration:
Open the Integrations overview and locate the Okta integration.
Click Actions > Enable Audit Logs.
To disable activity monitoring and incremental extraction, toggle the option to Disable Audit Logs.
On Edit Integration > Custom Properties tab, click Add Custom Property.
Enter the variable name region as the property name to collect.
Pick String as the property type.
Save the configuration.
The specified attributes will appear on Authorization Graph entities the next time Veza connects to the Okta domain.
The supported types are:
String
Number
Boolean
RFC339 Timestamp
String List
Veza honors RFC339 timestamp formats, such as: 2006-01-02T15:04:05Z07:00, 2006-01-02T15:04:05.999999999Z07:00, 2006-01-02 15:04:05Z07:00, 2006-01-02 15:04:05, 2006-01-02, 2006-01-02T, 2006-01-02T15:04:05, 2006-01-02T15:04:05Z Time values in the format "18:47:12.019Z" (that do not contain dates) are only supported in strings.
Veza can automatically detect relationships for Okta and AWS, Snowflake, and other providers. However, some connections to standalone data sources need to be explicitly mapped.
Administrators can disable default IdP User > Local User mapping by email when adding a custom mapping.
Administrators can configure up to four property matchers for custom identity mapping based on possible combinations of user name and email. If any matcher is valid, Veza connects the IdP and local identities.
Open the Okta provider configuration menu (Configuration > Identity Providers > Add or Edit)
Click Identity Mapping Configurations
Pick the Destination Datasource Type. The mapping will apply to all resources of the chosen provider (such as SQL Server).
Pick an optional transformation. By default, Veza will link identities based on email addresses (username@domain). To match only the username, use Ignore Domain. You can also ignore special characters in local usernames.
Veza gathers metadata and creates searchable Authorization Graph entities to represent:
Okta Domains
Okta Groups
Okta Apps
Okta App Users (Application Roles)
Okta App Group Assignments
Okta Users
Okta Roles (Administrator Roles)
If Veza does not detect an identity mapping from Okta to another integrated data source, you can define the relationships with
If your organization uses in addition to the standard properties collected by Veza, you can enable them on the Veza configuration screen.
For more information, see in the Okta documentation.
Click Next to configure optional . These mappings correlate Okta users with local accounts in other systems when Veza cannot automatically detect a connection.
Click Next to specify any you want Veza to discover.
By default, Veza discovers all Okta domains and applications in the account. You can deselect the "Gather All Applications" option to only sync specific apps based on the settings.
Support for , including generation of Over Provisioned Scores for Okta users.
Your Okta organization might add additional user metadata with . To include these custom properties during discovery, specify the Name and data Type of each property to collect.
For example, if your organization used a custom attribute to track employee region, you can use this information for by adding the custom property to the Okta integration configuration.
When submitting authorization metadata for custom apps with the , local users, groups, roles, and permissions are mapped to Okta identities by login email and group name.
Veza identifies Okta-AWS relationships based on the official app
Use to manually create a connection to another provider. For example, employees might be able to access a standalone SQL database with their Okta credentials:
Additional steps may be needed to fully gather enrolled MFA factors for Okta identities
Configure an Okta Network Zone that allows optional MFA factors
See below for more details and steps to enable:
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).
There are 2 options to allow Veza to fully collect MFA enrollment.
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.
Create a Veza MFA Enrollment Policy.
For Assigned Groups, enter the group created in step 1.
All authenticators are Optional (OIE requires 1 as Required).
Create a Veza Policy Rule:
IF User's IP is "in zone" (Add the Zone for Veza's Cloud IP Addresses)
AND User is accessing "Okta"
THEN Enrollment is "Allowed if required authenticators are missing".
Test the configuration by adding users to the group.
Veza should see everything and user experience should not be affected.
After testing, Remove the "Assigned" Group, and Apply the "Everyone" group.
If your Okta are such that traffic from 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:
Use an to connect to Okta from an IP address internal to your data center that does not have these restrictions
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 ).
Configure for under Gateway IPs.
Have Veza traffic to Okta run through an installed in your data center. This asumes your data center IP Addresses do not have the same restrictions as .