Application Outline

This document provides a high-level overview and examples for getting started with a new OAA connector to integrate Veza with SaaS applications, infrastructure systems, custom-built applications, and other systems. These examples use Python and the oaaclient SDK.

When developing a connector, the source systems and customer needs can require changes to code flow for different deployment scenarios. The overall goals, best practices, and flow will apply for most integrations:

Code goals

The sample code was written with the following goals in mind:

  • Connector should be easy to run from automation platforms and the command line.

    • Parameters are passed through environment variables as well as command line flags. This makes the code easier to package into containers or serverless stacks and control through outside configuration. Connectors by nature require secrets such as the Veza API key. Managing these through variables affords additional options for secrets management.

  • Connectors do not require state:

    • Connectors do not require any persistent data between runs.

    • There is no special invocation for the first run or subsequent runs.

    • The connector handles all of the logic for provider and data source creation internally, as needed, or by discovering existing ones.

      • Data Source name should be unique to the discovered environment. This can be achieved by including a hostname or instance ID in the data source name: discoverable by the code and consistent between runs. This ensures that two instances of the same connector do not interfere with each other if discovering separate instances of the application. When such a property cannot be determined, a command line parameter is an option.

  • Connector code is importable:

    • The flexibility to import connector code into another piece of Python code enables a setup wrapper to handle job management tasks such as:

      • Secrets management

      • Output logging

      • Other configurations required by the environment

    • A separate run function implements connector end-to-end logic. This can be imported and invoked by providing the necessary parameters. The main function that runs when invoked from the command line should only process command line inputs and environment variables for setup.

High-level code flow

The exact flow of the connector can change to meet specific requirements, but the general steps are as follows:

  1. Process and validate configuration parameters. Ensure you have supplied all necessary values such as host names, user names, and API keys.

  2. Call the main run function with all the required and optional parameters.

  3. Initialize the oaaclient connection to the Veza tenant. Initializing the client verifies that the Veza URL and API key are valid before starting any application discovery.

  4. Create an instance of the oaaclient.templates.CustomApplication to populate with the application information.

  5. Connect to the system and perform discovery of required entities:

    1. The discovery order for users, groups, roles, and so on can be changed based on relationships and interface.

    2. Populate the CustomApplication instance with the identity, roles and permissions, resources, and authorization information.

  6. Check if Provider and Data Source exist on Veza. Create them if they do not exist.

  7. Push the application to the Data Source. The SDK creates the JSON payload from the CustomApplication instance.

    1. Process any returned warnings or errors.

  8. Exit.

Implementing from the example

  1. Update the Provider Name, App Type, and Application Name based on the source system. These values will typically be set to the product name. The data source name must be unique - check that an appropriate distinguishing value such as hostname is included in the data source name. For more information on naming, see Providers, Data Sources, Names and Types

  2. Define any custom properties needed in the __init__ method. Properties must be defined on the CustomApplication entities before setting them.

  3. Implement the discovery steps for the discover() function to collect Users, Groups, Roles, and any resources for the application. As the entities are discovered, add them to the CustomApplication object using the appropriate SDK operations.

  4. Run the connector to validate the output in Veza.

  5. Automate the connector to run on a regular schedule.

Code walkthrough for custom application

The code below can serve as a template and the comments explain the reasoning beyond the patterns.

Last updated

Was this helpful?