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 adds a schema, the schema inherits permissions from the data source. 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:

• Managing Default Access Policies

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 model artifacts. Like onboarded data, registries are stored and managed as RDF named graphs according to system ontologies.

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
• Graphmarts
• Unstructured Pipelines
• Users and Roles
• Role Permissions and Registries

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.

Graphmarts

When a user creates a graphmart from scratch, the graphmart is assigned permissions according to the Graphmarts Registry Default Access Policy. When a user creates a graphmart from a data source, the graphmart inherits permissions from the source schema.

Graphmarts contain data layers that describe and group the transformations that take place as the knowledge graph is generated. Since layers 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 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 layers and steps.

To summarize the inheritance rules for graphmarts:

• Graphmarts created from scratch via the Add Graphmart button inherit permissions from the Graphmarts Registry Default Access Policy.
• Graphmarts created from a data source inherit permissions from the source.
• Data layers and steps created in a graphmart inherit from the graphmart.

For more information about graphmart permissions, see Sharing Access to Graphmarts.

Unstructured Pipelines

Running an unstructured pipeline produces a dataset, which inherits its permissions from the pipeline. Additionally, each 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 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.

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 Role and Permissions 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:

• Anyone who has the Manage Users, Groups, and Roles permission has the Admin level of access to all users, groups, and roles.
• The Everyone role has View access to all users, groups, and roles so that they can share artifacts with other users and groups.

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 Role and Permissions 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 Share Access to Artifacts.