> For the complete documentation index, see [llms.txt](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates.md). # OAA Templates JSON schemas for describing custom applications, identity providers, principals, file systems, and other authorization sources OAA utilizes templates (JSON schema) for structuring authorization and identity metadata, combined with a REST API to register, update and manage the data. Once uploaded, Veza processes the template payload and incorporates the entities and permissions into the Authorization Metadata Graph. Choosing the appropriate template is the first step in creating a new integration with OAA. The template provides a schema for describing the identities, resources, and authorization relationships local to the OAA data source. ### Custom Application For most applications, SaaS Apps and systems the [Custom Application Template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/custom-application-template.md) provides a generic and flexible model to capture authorization data for users and groups to the system and its resources. A custom application is structured with the following main entities: * Application * Resource * Sub-resource * Sub-resource * Additional sub-resources * Local Users * Local Groups * Local Roles * Local Permissions * Identity-to-permissions binding ### Custom Identity Provider Intended for modeling sources of users, group, and federated identity metadata, the [Custom Identity Provider Template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/custom-identity-provider-template.md) can be used to enumerate users and groups that access other external applications and resources, similar to built-in connectors for Okta and AzureAD. These users and groups typically represent the top-level corporate identities within an organization. A Custom Identity Provider can have the following entities: * Domains * Users * Groups The Custom IdP template also includes the option to define AWS Roles that are assumable by users and groups and can work with Access Review Workflows to auto-assign resource managers. ### Custom Principal For modeling sources of identities (users, groups, and tenants) that connect to other OAA data sources on the same provider, the [Custom Principal Template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/custom-principal-template.md) provides a lightweight identity model. Unlike the Custom IdP, which models a full identity provider with domains, the Principal template is designed to feed users and groups into Custom Application or other templates on the same provider. A Custom Principal is structured with: * Tenant * Users * Groups ### Custom HRIS Provider For publishing employee metadata from an HR platform, the [HRIS Template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/hris-template.md) captures employment status, reporting lines, and organizational units. Unlike an identity provider, an HRIS does not usually grant access to other systems, so this template feeds Lifecycle Management events, identity correlation, and Access Review enrichment rather than authorization paths. An HRIS submission is structured with: * System * Employees * Groups ### Secret Store For modeling secret and credential management systems, the [Secret Store Template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/secret-store-template.md) captures vaults, entries, permissions, and identity access mappings. Use this template to connect custom or self-hosted credential management systems that are not covered by a native Veza integration. A Secret Store is structured with: * Secret Store * Permissions * Vaults * Entries * Identities * Identity-to-Permission Bindings ### Entity Enrichment The [Entity Enrichment Template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/entity-enrichment-template.md) adds custom property values to entities that already exist in the Veza authorization graph from other integrations. Use this template to attach supplemental metadata (such as compliance status, cost center, or internal identifiers) to entities discovered by native integrations. An Entity Enrichment submission contains: * Enriched entity property definitions (schema declarations) * Enriched entities (entity references with property values) ### File System For modeling file servers and file storage platforms, the [File System Template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/file-system-template.md) captures which identities hold which permissions on servers, shares, and directories. Use it for storage systems that are not covered by a native Veza integration. A File System has two submission modes, one for a server and its mounts and one for the folders within a mount: * Server * Mounts * Folders * Permissions * Identity-to-permission bindings ### CMDB For bringing asset inventory into Veza, the [CMDB Template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/cmdb-template.md) captures configuration items from a configuration management database and correlates each one to the identity that owns it and to the Veza entity it describes. A CMDB submission is structured with: * CMDB instance * Configuration items * Owner and asset correlation configuration ### Secret Scanner For submitting findings from an external secret scanning tool, the [Secret Scanner Template](/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates/secret-scanner-template.md) records where credentials were found in source control so they can be correlated with matching credentials in Azure Key Vault. Unlike the other templates, a submission is a single flat list of findings with no entity hierarchy. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.veza.com/4yItIzMvkpAvMVFAamTf/developers/api/oaa/templates.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.