The Anjana Data Platform plugins are the components that allow connecting the platform with technologies from the organization's data and identity ecosystem (cloud, on-premise, BI, data lakes, technical catalogs, etc.). Each plugin is specialized in a specific technology —for example, AWS S3, Azure Storage, GCP BigQuery, Entra ID, Denodo, Tableau or Power BI— and enables native integration capabilities with the Anjana Data Platform operational governance model.
This section documents the plugins available in version 25.2 and their functional behavior. The specific technical configuration for each technology is detailed on its corresponding page.
Common functional capabilities of the plugins
Although each plugin depends on the target technology, most Anjana DataPlatform integrations rely on four main capabilities:
1. Metadata extraction
Allows discovering and importing assets from the source technology into Anjana Data Platform (datasets/tables, fields/columns, processes, views, reports, etc.).
The extracted metadata is transformed into entities of the operational metamodel so they can be governed in the Data Portal.
Examples: AWS Glue, Generic JDBC/Oracle/SQL Server/Redshift, Denodo, Azure Storage, GCP BigQuery, Ranger.
2. Data sampling (sample data)
Some plugins allow retrieving a controlled sample of the data associated with a dataset for visualization from the “Sample Data” tab in the asset detail.
This capability is subject to permissions, technical limitations of the source platform, and security rules of the operational model (See information about the isGoverned and sampleData attributes).
Examples: Azure Storage, GCP Storage, BigQuery, JDBC engines.
3. Active governance of access permissions
The active access governance plugins materialize, in the external technology, the data or report access decisions established at the governance layer through Data Sharing Agreements (DSA).
Depending on the technology, active governance may involve:
-
Provisioning of groups or roles that represent a DSA.
-
Automatic management of members/users according to adherence and non-adherence.
-
Assignment or revocation of permissions on governed physical structures (tables, views, buckets, paths, etc.).
Examples:
-
Identities: Entra ID, AWS IAM, GCP IAM, LDAP/AD.
-
Data: Azure Storage (via Entra ID), AWS S3 (via IAM), GCP Storage/BigQuery (via IAM), Denodo (via LDAP or Entra ID), Ranger.
Note on decoupled provisioning of groups and roles
The provisioning of groups and roles in external systems is decoupled. This means that, through configuration and metadata of the DSA itself, it is possible to omit the automatic creation and management of groups by Anjana Data Platform.
Specifically, if during the creation of a DSA the physicalName attribute is populated with the identifier of an already existing group in the organization, the plugin reuses that group instead of creating a new one. From that point on, role and permission provisioning is performed according to the indicated physicalName, maintaining active governance over the resources without needing to manage the group lifecycle from Anjana Data Platform.
This functionality is especially attractive in scenarios such as:
-
When the organization does not want to delegate group creation/deletion to the Anjana Data Platform plugin, but does want to leverage automatic member/user management (additions and removals by adherence/non-adherence).
-
When corporate group naming policies do not fit the standard Anjana Data Platform convention (prefix + logical DSA name + version), and it is required to maintain pre-existing or externally managed proprietary names.
-
When there are already consolidated groups in the identity provider (for example, departmental or product-based groups) and the DSA must rely on them to avoid duplicates and simplify administration.
-
When group management is controlled by internal processes or external tools, and Anjana Data Platform must integrate without interfering with that lifecycle.
-
When historical access continuity is to be maintained: reusing an existing group allows audits, traceability, and dependencies in external systems to continue referencing the same identifier.
4. Synchronization / technical operations
Some plugins, in addition to extracting or governing, can perform technical synchronization operations to maintain consistency: tag updates, policies, etc.
DSA naming convention in identity systems
When a plugin represents a DSA as a group (Entra ID, AWS IAM, LDAP/AD) or as a role (GCP IAM), Anjana Data Platform generates these artifacts by default following a uniform naming convention:
<configurable prefix>_<logical DSA name>_v<DSA version number>
Where:
-
<configurable prefix>identifies the groups/roles managed by Anjana Data within the provider. -
<logical DSA name>is the functional name of the agreement as it appears in Anjana. -
v<version number>allows distinguishing coexisting versions (approved, deprecated, or historical) and maintaining traceability between systems.
This convention applies whenever the DSA does not indicate a pre-existing physical artifact.
In scenarios where it is desired to reuse a group already managed by the organization, the physicalName attribute can be populated during DSA creation. In that case, the plugin does not create a new group, but uses the one identified in physicalName and materializes active governance (roles/permissions and memberships) on that artifact.
Each technology may impose additional restrictions on the length or valid characters for groups or roles. These restrictions are detailed on the specific page for each plugin.
Multi-connection (since version 25.1)
Since version 25.1, plugins that support it allow configuring more than one connection per technology. This facilitates integrations by environment (dev/prod), by region, or by different accounts/projects.
In the functional configuration, a list of connections is defined, each with its ARI and technology-specific properties. The detailed technical configuration and YAML examples are available in Nexus and on the specific pages of this section.
Extraction path separator (path separator) (since version 25.2)
The extraction path separator (path separator) is a configurable parameter that determines how logical paths (the path attribute) are interpreted and constructed during metadata extraction, object location, data sampling, and active governance in the integrated technologies.
By default, Anjana Data Platform uses the / character as the path separator. However, in scenarios where data structures include this character as part of table, view, or resource names, an alternative separator can be configured to ensure correct extraction.
Separator configuration
For the separator to work consistently, it must be configured with the same value in all involved components: Kerno, Tot, and the corresponding plugins.
In Kerno
anjana.tot.extraction.pathSeparator: "/"
In Tot
tot.extraction.pathSeparator: "/"
In plugins
-
Power BI and Tableau:
totplugin.pathSeparator: "/"
-
Other plugins:
totplugin.connection.<connectionName>.technology.pathSeparator: "/"
Character restrictions
-
Any character can be used, except
:, due to limitations of some underlying technologies. -
If the
\character is to be used, it must be declared as\\in the YAML file to be interpreted correctly.
Important considerations
Note
If the AWS IAM, AWS S3, and/or Azure Storage plugins are used, this parameter must not be explicitly configured in Kerno, Tot, or the plugins. In these cases the default value must be maintained.
Important
The path separator is defined during the initial installation of the platform and must not be modified afterwards, as it is a critical element for:
-
the correct location of objects in the source technologies,
-
metadata extraction,
-
data sampling, and
-
active permission governance.
If it is strictly necessary to change this value in an already operational installation (with governed assets), the following procedure is recommended:
-
Download the metadata of the governed assets to Excel prior to the separator change (Download for editing)
-
Delete the governed assets prior to the separator change
-
Edit the downloaded Excel and modify the separator in the path field according to the new separator
-
Re-catalog the assets by loading the modified Excel
If in doubt, it is recommended to contact Anjana Data Support beforehand.
Additional plugin considerations
More information
For specific information, consult the documentation for each plugin.
For all plugins there are common guidelines collected in the Technical configuration and Tot plugin deployment sections.
Additionally, for each plugin an example YAML is available to facilitate its deployment. This file includes the description of each property and its default values, so it can be copied and adapted to the client installation.
Plugins that support it allow configuring multiple connections to different instances of the same technology (for example, different accounts, projects, or environments). This capability, as well as its syntax, is also illustrated in the corresponding example YAMLs.