If you can't find the product or version you're looking for, visit support.ataccama.com/downloads

Configuring Permissions Frequent Scenarios

Current page is describing the examples of the most frequent scenarios of configuring permissions.

Scenario 1: Removing default permissions on entity

Permissions, that are not propagated from the metadata, can be revoked from the Access table by hovering over permission and clicking on the bin sign:

configure permissions frequent scenarios revoke permissions

However, those permissions that were propagated from the metadata and have a corresponding node icon, can not be deleted that way. To delete entity permissions that were propagated from the Metadata, the GraphQL mutation needs to be used:

For more information on GraphQL usage see one-api.adoc.

Open the Playground by adding /playground/ to the URL line of the page.
Run the following mutation query, where:
- Specify the <UnassignCapability> you would like to revoke
- Specify the <capabilityID> you would like to revoke.
- Specify the <gid> of the source of the permission, which in case of Metadata is "00000000-0000-0000-0000-000000000001".
- Specify the <roleID> or <userID> you would like to remove permission from.
  mutation metadataUnassign { <UnassignCapability>( capabilities: "<capabilityID>" gid: "00000000-0000-0000-0000-000000000001" grantingStrategy: GRANT roles: "<roleID>" // or users: "<userID>" ) { result { gid } } }
  For example, to remove Viewer rights from Emil Pokus on a specific Catalog Item, the following mutation is used:

To run the queries correctly, the IDs of users, roles, capabilities and source of permissions granting (gid) are required.

It is possible to get the gid of the specific entity by doing the following:

Navigate to the entity you would like to manage permissions for.
Copy the GID from the URL ending. For example, the Catalog Item "offices" has the gid: "`9bb0b0f6-6aa0-4a77-9377-4b2abc9bb11b/"`.

It is possible to get all default permissions assignments in Metadata by running the following query:

Click here to expand…

query {
  metadata(gid: "00000000-0000-0000-0000-000000000001") {
    gid

    assignedIdentities {
      grantingStrategy
      capability {
        name
        id
      }
      identity {
        __typename
        ... on Person {
          id
          firstName
          lastName
        }
        ... on Role {
          name
        }
      }
      source {
        nodePath
        type
        gid
      }
    }
  }
}

It is possible to get permissions assignments on specific source, for example, Catalog Item, by running the following query, where GID is the ID of the Catalog Item:

Click here to expand…

query {
  catalogItem(gid: "07117d52-1725-43ca-bda4-03f773b8fe7a") {
    gid
    draftVersion {
      name
    }

    assignedIdentities {
      grantingStrategy
      capability {
        name
        id

      }
      identity {
        __typename
        ... on Person {
          id
          firstName
          lastName
        }
        ... on Role {
          name
        }
      }
      source {
        nodePath
        type
        gid
      }
    }
  }
}

Scenario 2: Restricting permissions on data preview

There are three major ways how to restrict preview of the data:

To revoke permission on previewing data from all Viewers, go to Organization > Permissions Model and remove the viewer Operation Set where preview operation is added.

configure permissions frequent scenarios restrict permissions

To revoke preview permission from a specific user, the user’s roles needs to be managed. If the user is already assigned to a role that has a permission to see the preview of data, the permission cannot be revoked for a user while saving his role and the role’s permissions.

For example, if the user is assigned to a role that has rights to see all catalog items, it is impossible to restrict the user’s permission to one specific catalog item. Restrict the user’s permissions in that case is only possible via the following way:

Remove the mapping of user and role in Keycloak or another identity management system you are using.

If there are several users who should not be able to preview the same catalog items, another role can be created for them.
Create a capability in permissions.json, that has no operation "preview".

Assign the capability to a user on each location one by one where the user needs to have permissions.

For example, if Emil Pokus is assigned to the role catalog_admin but it appears that he should not be seeing the data preview of one specific Catalog Item, he should be unassigned from the role catalog_admin and assigned to all catalog items he needs to have access to via Access tab on each Catalog Item.

Scenario 3: Creating custom capability and assigning it to a Keycloak role

For guidelines on how to create a new capability see Manage Permissions of Users and Roles, Configuring custom permissions section. Capabilities are applied to a specific location, or in other words, entities, such as Catalog Items or DQ Projects.

To assign a Keycloak role to a newly created capability, go to the location the capability refers to, and map role and capability on the Access tab. For more information see Manage Permissions of Users and Roles, Granting, sharing and revoking permissions section.

Scenario 4: Restricting user permissions to one DQM project

To revoke permission from a specific user, the user’s roles needs to be managed. If the user is already assigned to a role that has a permission to DQ Project, the permission cannot be revoked for a user while saving his role and the role’s permissions. For example, if the user is assigned to a role that has rights to edit all DQ Projects, it is impossible to restrict the user’s permission to one specific project. Restrict the user’s permissions in that case is only possible via removing the mapping of user and role in Keycloak or another identity management system you are using.

For example, if Emil Pokus is assigned to the role dq_admin but it appears that he should not be able to edit some specific DQ projects, the following should be done:

Emil Pokus should be unassigned from the role.
He should be assigned to all DQ projects as an owner where he needs to have access to via Access tab on each DQ project. Assign the editors rights to a user on each project one by one where the user needs to have permissions, and ignore projects where the user should not be an editor.

Scenario 5: Restricting user editor permissions to attributes

There are two options to restrict users' edit rights on attributes. Currently it works as "all or nothing", which means you can either edit all attributes or you don’t edit any for all users.

The first option is to restrict users' edit rights from all attributes on a catalog item. To do that, follow these steps:
1. Remove the user from the role which has the capability to perform editors actions on a catalog item everywhere.
2. Create a specific capability on attributes, for example, without the operation "name": "core:edit".
3. Then attributes need to be shared one by one. But this case will be deprecated in the next ONE versions.
To revoke editing permissions from users on the attributes, do the following:
1. Remove the user from the role which has the capability to perform editors actions on a catalog item everywhere.
2. Create a new capability on a catalog item that would restricting editing of all attributes, for example, without "name": "core:edit" operation.
3. Assign new capability on a Catalog Item to a user on an Access tab. Grant permissions to a user again on all other Catalog Items that he needs to have access to.

Scenario 6: Configuring and assigning access to a custom entity

When creating top-level custom entity (the one that goes to the left hand menu), ownership permissions to this entity on metadata need to be set first. Example in permissions.json, source_admin has permissions on root ( "/") which means source admin on metadata can create new drafts and therefore can create new sources. Similar capability is needed for new top-level entity creation.

Other custom entities that are located underneath other sections, like Glossary, Catalog, etc. inherit permissions of the source. Permissions can be changed on the Access tab of the newly created entity.

Was this page useful?