Artifact Access Control Concepts

The implementation of artifact and data access control in Anzo is an aggregation of three mechanisms:

  1. Default Access Policies: These are the base permissions that are applied to artifacts by default when they are created. For most types of artifacts, the access control that is supplied by a Default Access Policy is augmented by the other two access control mechanisms.
  2. Permission Inheritance: To facilitate common workflows, the Anzo application applies logic so that artifacts in the same workflow inherit the same permissions. For example, when a user creates a data source and uses the Ingest workflow to onboard the data, the generated model, pipeline, and mapping artifacts inherit their permissions from the data source. Once the pipeline is published, the resulting data set inherits the permissions from the pipeline. This permission inheritance is applied in addition to the applicable Default Access Policy.
  3. Sharing: An artifact's creator can also share access to their artifact with other users or groups. When an artifact is shared, those user-configured permissions are applied in addition to any permissions that were inherited.

The following diagram illustrates the above concepts. Details about the processes and components depicted in the diagram are provided in the sections below.

Default Access Policies

Default Access Policies are the security policies that are applied by default to the artifacts that belong to a particular system registry (see Registries below). Default Access Policies are the base permissions that get assigned when an artifact is created—before any other access control logic (e.g., Permission Inheritance) is applied. Any artifact-level logic that is applied by Anzo or configured from the Sharing tab in the Anzo application augments the permissions that were supplied by the Default Access Policy.

For more information about Default Access Policies, see the following topic:

Registries

A registry is a system-level graph that stores metadata about artifacts of the same type. For example, a Data Sources Registry stores metadata about all of the data source and schema artifacts, and an Ontology Registry stores metadata about all of the data model artifacts. Like onboarded data, registries are stored and managed as RDF named graphs according to system ontologies.

Aside from changing the Default Access Policy for a registry, do not make additional modifications to registries. Changing or removing a registry can irreparably damage your Anzo server.

Permission Inheritance

The concept of inheritance is fundamental to the implementation of access control in Anzo. Inheritance allows related entities to share permissions with each other, making access easier to manage collectively, and ensuring that users have the appropriate access to each of the dependent artifacts that are crucial to their workflow. The following subsections describe the relationships and inheritance rules for each type of artifact.

Data Sources & Schemas

Data sources and schemas have a fundamental relationship since schemas are imported from data sources and, in a sense, belong to them. Because a data source can have more than one schema and the schemas can be managed independently, data sources and schemas exist as separate artifacts in Anzo. However, because of their implicit relationship, Anzo uses inheritance to facilitate users' interaction with data sources and the schemas created from them.

If Anzo did not apply inheritance, a user who shares a data source would have to remember to add the new user to the data source and navigate to each related schema and add the new user there as well. Keeping permissions in sync manually presents a big challenge that is curtailed by applying inheritance.

To summarize the inheritance rules for data sources and schemas:

  • Schemas inherit from the data source from which they were imported.
  • Schema instances, which link schemas to their data source, inherit from both the schema and the data source.

Ingest Workflow

A primary workflow in Anzo is to create a new data source and then use the Ingest workflow (sometimes referred to as "auto-ingest") to generate all of the artifacts that are needed onboard the data and create the corresponding graph Dataset in Anzo. Artifacts created from the Ingest workflow inherit their permissions from the original data source.

If Anzo did not apply this inheritance, a user who wanted to share the Dataset that was derived from a data source would need to manually edit permissions for every artifact in the workflow: model, mappings, and pipeline.

To summarize the inheritance rules for the Ingest workflow:

  • Models generated by the Ingest workflow inherit permissions from the data source.
  • Mappings generated by the Ingest workflow inherit permissions from the data source.
  • Pipelines generated by the Ingest workflow inherit permissions from the data source.

In rare cases when inheritance rules do not apply to artifacts, such as if a user manually creates a mapping outside of the Ingest workflow, the Default Access Policy would supply the permissions for that mapping until permissions are configured from the mapping's Sharing tab.

Graphmarts

When a user creates a graphmart, the graphmart is assigned permissions according to the Graphmarts Registry Default Access Policy. Graphmarts contain layers and steps that describe and group the transformations that take place as the knowledge graph is generated. Since layers and steps are created in the context of a graphmart, they inherit their permissions from the graphmart by default.

If Anzo did not apply this inheritance, a user who wanted to share a graphmart would have to remember to configure each newly created layer or step to assign permissions that match the graphmart's permissions. Otherwise someone who had access to the graphmart would not be able to view or edit its components.

To summarize the inheritance rules for graphmarts:

  • Graphmarts inherit permissions from the Graphmarts Registry Default Access Policy.
  • Layers created in a graphmart inherit from the graphmart.
  • Steps created in a graphmart inherit from the graphmart.

For more information about graphmart permissions, see Graphmart, Data Layer, and Step Sharing.

Structured Pipelines

When a structured pipeline is published, it creates a Dataset. Since the most common data ingestion workflow is for a user to introduce a data source and then ingest the data into a Dataset by running a pipeline, Datasets created from a pipeline inherit their permissions from the pipeline. If Anzo did not apply this inheritance, a user who has access to a pipeline might lose the ability to see its output if the pipeline happened to have been run by someone else first, for example.

To summarize the inheritance rules for structured pipelines:

  • Datasets created from structured pipeline runs inherit from the pipeline.
  • Datasets created from auto-generated structured pipelines inherit from the original data source that was used to generate the structured pipeline.

Unstructured Pipelines

As with structured pipelines, running an unstructured pipeline produces a Dataset. For similar reasons, the output unstructured Dataset inherits from the unstructured pipeline. Additionally, each unstructured pipeline run produces a status dataset that is specific to the pipeline's execution. Since these status datasets are implicitly related to the unstructured pipeline, they inherit permissions from the pipeline.

To summarize the inheritance rules for unstructured pipelines:

  • Datasets created from unstructured pipeline runs inherit from the corresponding unstructured pipeline.
  • Pipeline status datasets inherit from the related unstructured pipeline. From an end user's perspective, this relates to the status information that is displayed in the unstructured pipeline user interface.

Metadata Dictionaries

Users can create metadata dictionaries from specific data sources. Because the dictionary is directly related to the origin data source, metadata dictionaries inherit their permissions from the corresponding data source. If one dictionary is used for multiple data sources, the dictionary inherits the superset of permissions from the origin data sources.

To summarize the inheritance rules for metadata dictionaries:

  • Dictionaries generated from data sources inherit from the data source.
  • Dictionaries that link concepts from multiple data sources inherit from all corresponding data sources.

Users and Roles

Users and roles are typically managed by administrators as a collective group. There are not clear use cases for a given user to manage some user and role accounts but not others. The expectation is that users who have the Manage Users, Groups, and Roles permission should be able to manage all users and roles, not just a subset of them.

To accomplish the above expectation, all users inherit permissions from one system registry, the Users Registry. If user and role permissions were not centralized, there could be circumstances where one user creates a new user or role in Anzo and other users cannot see or edit that account even if they belong to a role that has the Manage Users, Groups, and Roles permission. Also if the original user or role creator had the Manage Users, Groups, and Roles permission revoked, they may retain control over the accounts they created when they had the ability to do so.

To summarize the inheritance rules for users and roles:

  • All users inherit from the Users Registry.
  • Anyone who has the Manage Users, Groups, and Roles permission has the Admin level of access to all roles.

Role Permissions and Registries

Access to certain registries is mapped to specific Anzo permissions. This is helpful when artifacts that are added to a registry inherit their permissions from the registry itself rather than another artifact, such as with Users and Roles. When users have a permission that grants them access to a registry, that means they can see all artifacts that belong to that registry.

The list below describes the registry access that is controlled by a permission.

  • Access to the Users Registry is granted by the Manage Users, Groups, and Role permission.

For more information about the Anzo permissions, see Role Permissions Reference.

Sharing

Artifacts can be shared with other users and groups from the artifact's Sharing tab in the Anzo application. When an artifact is shared, those user-defined permissions are added to the set of permissions that came from the Default Access Policy for the related registry as well as the permission inheritance that is applied by Anzo.

For details about artifact sharing, see the following topic:

Related Topics