As the identity-first security platform for data, Veza is focused on empowering you to answer one vital question: who can, and should, take what action on what data? To do this, Veza ingests authorization data from your IdP (Okta, Azure AD) your cloud providers (AWS, GCP, Azure), and your data assets themselves (Cloud storage buckets, Snowflake, SQL databases, SaaS apps) and normalizes this complex metadata into “effective permissions”: who can create, read, update, delete your sensitive data.
By connecting your data sources to Veza’s authorization platform, you can:
Visualize identity-to-data relationships for all human and machine identities in your organization.
Constantly monitor for authorization misconfigurations and violations, and automate the first steps of remediation.
Conduct fast and effective entitlement reviews of the real permissions of users to sensitive data.
The connectivity problem: many sources of sensitive data are unique
To be truly effective as an authorization platform, Veza needs to be able to capture a complete picture of the sensitive data your organization holds. However, not all data lives in platforms covered by Veza’s standard integrations. In fact, for many organizations, the source of their most sensitive data is their own purpose-built applications, developed over the course of years and totally unique. These applications can contain protected internal data, or enable access to customer data. For example:
A hotel chain builds a custom reservation management system, handling payment details and customer PII for more than half a million rooms.
A technology company builds a custom portal to enable support engineers to access customer deployments.
A financial technology company uses a software platform to give developers access to multiple databases containing sensitive and regulated information.
A financial technology company builds a custom dashboard tool to show confidential metrics.
No productized connector or integration could ever be available for these data sources, yet any comprehensive effort to protect an organization’s sensitive data and prevent excess privilege must include them.
The solution: Open Authorization API
To enable you to truly fold all sources of sensitive data into a single control plane for authorization, there’s Veza’s Open Authorization API (OAA). OAA enables organizations to integrate the authorization metadata from their own unique applications directly into the Veza platform to give the same visibility into these data sources that Veza provides out-of-the-box for AWS, Azure, GCP, Snowflake and others.
With OAA, customers can develop their own integrations with Veza to provide the metadata on who and what makes up their custom application, along with the authorization information on what users or groups have what roles and permissions. This information is compiled into a JSON template and pushed to Veza using a REST API. Veza combines this information with metadata from other sources, like Identity Providers (Okta, AzureAD) in the Authorization Graph.
By importing their authorization metadata with OAA, organizations can leverage all the power of the Veza Platform including reporting, alerting and entitlement review workflows.
Developing for OAA
Veza publishes a Python SDK to make it easier for customers to integrate with OAA. For organizations that would like to develop in other languages, OAA simply requires being able to work with JSON and REST APIs.
The OAA workflow is made up of three steps:
Extract the authorization information from the source application including user, groups, resources and the roles and permissions associated with those identities. This is typically done through the applications APIs but can also be accomplished through direct database connections, reading configuration files or even parsing the source directly.
Format authorization information into the OAA JSON schema, either directly or by using the Python SDK. The schema is flexible enough to meet many different application designs. It even supports ingesting custom properties of users and resources, enabling richer reporting, queries and alerts in the Veza platform.
Upload to Veza via a simple API request.
Install the Python SDK
# pip3 install oaaclient
The oaaclient SDK provides the tools necessary to communicate with Veza and to populate the applications’ authorization information into the OAA template.
Create a custom application
Using the SDK you can create a new CustomApplication object and populate authorization information.
Define authorization metadata
Once the application object is set up it can be populated with users, groups and resources. This provides the information on the “who” and the “what” for the application.
OAA entities for the application’s users and groups can contain additional metadata. For example, whether the user is active, or last login time. These types of metadata can support reports and alerts to clean up inactive users. Even custom metadata from the application can be applied to further improve filtering and reporting.
for app_user in api_get("/api/v1/users"): oaa_user = custom_app.add_local_user(app_user.name, identities=[app_user.email]) oaa_user.last_login_at = app_user.last_login oaa_user.is_active = app_user.active for group in api_get("/api/v1/groups"): # create the group custom_app.add_local_group(group.name) # add the members for member in group.members: custom_app.local_users[member].add_group(group.name)
Now that the users, and groups have been populated, they can be connected to the authorization information. The first step is to define the authorization permissions for the application. These can be general permissions like “Admin” or “User”, or specific actions like “close_ticket”.
custom_app.add_custom_permission("admin", [OAAPermission.DataRead, OAAPermission.DataWrite, OAAPermission.DataDelete] ) custom_app.add_custom_permission("operator", [OAAPermission.DataRead])
Permission definitions include canonical “CRUD” verbs. This allows for Veza users to understand the effective permissions of a custom app’s users, even if they are not experts in its data architecture. Queries, alerts, and audits can be performed on either the verb from the application ( “users who have Admin”) or on the CRUD permissions (“users who have write permissions”). By adopting a common schema for describing effective permissions, you can use Veza to design protections, remediate excess privilege and other misconfigurations, and conduct access reviews across your entire stack.
Lastly, the authorization data to connect the identities to the resources are applied.
# get the list of user/group permissions for auth in api_get("/api/v2/permissions"): if auth.type == "user": # if the permission is for a user, add the permission to the OAA local_user custom_app.local_users[auth.user_name].add_permission(auth.permission, apply_to_application=True) elif auth.type == "group": # if the permission is for a group, add it to the OAA local_group custom_app.local_groups[auth.group_name].add_permission(auth.permission, apply_to_application=True)
In this example the application returns a list of permissions that are assigned to users or groups. The code can loop through this and assign the permissions to the users and groups that had been previously created.
Upload to Veza
The last step is to upload the data to Veza for processing. The SDK provides methods to simplify the connection, authentication and formatting of the upload.
# provide the connection details to the client veza_con = OAAClient(url="https://myveza.vezacloud.com", api_key="abc123...") # create a Veza provider for your application veza_con.create_provider("My App", custom_template="application") # push the contents of the custom_app response = veza_con.push_application(provider_name="My App", data_source_name="production-site", application_object=custom_app)
You can refresh authorization information from your application and re-upload to Veza at any cadence that makes sense for your application.
Sample apps are available in the OAA community.
Veza also publishes OAA Connectors for a number of popular SaaS applications, and that list is ever expanding. These integrations are ready to use but can also be a reference for developing your own integrations. You can see the available connectors on GitHub.
By taking advantage of the Open Authorization API, you can create a true single control plane for authorization to all sensitive data in your enterprise, whether it lives on premise or in the cloud, in a SQL database, or a unique custom application. To learn more:
A field guide to bad permissions part 2: expired permissions
Why expired permissions go unnoticed The main reason expired permissions go unnoticed is that it’s…
A field guide to bad permissions, part 1: ungoverned permissions
That is, permissions that aren’t captured or tracked in the tools you use for access governance,…