Ataccama ONE Agentic ONE Desktop ONE DQ&C ONE MDM ONE RDM ONE Runtime Server
latest (17.2.0) 17.1.0 17.0.0 16.3.x 16.2.0 16.1.0 16.0.0 15.4.0 15.3.0 15.2.0 15.1.0 14.5.x 13.9.x 13.8.x 13.7.x 13.6.x 13.5.0 13.4.x 13.3.x 13.2.x
Downloads

Manage and Explain Access to Assets

Sharing access is the means of providing access to other groups and users on the asset level. If a data asset is not shared and no stewardship group is selected, it is only visible to the user who created it. By default, this user gets the Full access level to this asset.

If default settings are used, only administrators or users with the appropriate sharing permissions can manage the access rights for a data asset. For example, a user who is a member of Group A and has full access level rights can share this group’s catalog items with the whole Group B or particular users from Group B. This can be configured through the manageAccess operation settings for each entity for each access level. For more information, see Access Levels.

You can monitor the manageAccess operation in the Audit module. This includes information about the users, groups, and access levels involved in the operation. For more information, see Audit.

To check which operations a specific user can perform on an asset and which share, stewardship assignment, or governance role decides each of them, use the Explain permissions report. See Explain permissions.

How sharing works

Before sharing access to assets with other groups and users, get familiar with how sharing functions. It mainly depends on the group hierarchy, user roles, and inheritance.

Therefore, consider how your assets should be shared when creating the group structure. For more information, see Groups.

How sharing works for groups and users

When sharing access with a group or a specific user, keep in mind that:

  • A user receives access to all data assets that are shared with the group of which this user is a member.

  • When sharing a data asset with a group, all members always receive the lowest access level possible as determined by the following:

    • Their governance role within the group.

    • The access level that was selected when the data asset was shared.

      The governance role that applies is the one the user holds in their own group, even when the asset is shared with a parent group. If several governance roles apply, the most permissive one is used. See How governance roles limit access.

      If a user has a governance role in a group with a View Data access on a rule, and someone shares this rule with the user’s group with an Edit access level, this user still has only a View Data access to this rule.

      Similarly, if a user has a role with a Full access in a group, and someone shares a rule with the user’s group with an Edit access level, this user gets only Edit access rights on this rule.

  • If you share a data asset with a specific user only (and the asset is not shared with the group this user is a member of), the user gets the access level selected when the asset was shared with them. The user’s governance role in any group has no impact on sharing in this case.

  • If you share a data asset with a specific user and with a group this user is a member of, the user receives the highest access level available between the one that is allowed by the user’s governance role within this group and the access level selected when the asset was shared with the user directly.

    If a user has a governance role in a group with a View Data access on the term entity, and someone shares a term with both (the user’s group with an Edit access level and with the user specifically with Full access level), the user gets a Full access to this term.

    Similarly, if someone shares a term with the user with only a View metadata access level, the user still gets View Data access rights on this term.

  • All users in a parent group automatically receive access to all data assets that are shared with at least one child group with the same access level settings. The same applies to any previous ancestors on the group hierarchy tree. This concept is called oversight.

    For example, we have three groups in a hierarchy as follows: Group A > Group B > Group C. If a catalog item is shared with an Edit access level with Group C, both Group B and Group A receive an Edit access level on the shared catalog item. The group Organization also gets an Edit access to this catalog item as the top parent group.

    Oversight concept diagram

    Additionally, the oversight is single-direction only: all ancestors receive access, but the descendants of those ancestors do not.

    Let’s take a look at the following hierarchy: Group A > Group B and Group A > Group C. If a catalog item is shared with an Edit access level with Group C, Group A receives an Edit access level on the shared catalog item, but Group B does not receive access to this catalog item.

    Inherited access example

    If you want to share access only with the top-level group, such as Organization and nobody else, you can create a separate group under Organization with the same users and share access with this newly created group. That way, only these particular people get access to the entity you’re sharing.

  • All users in the child groups receive access to all data assets that are shared with a parent group.

    For example, we have four groups in a hierarchy as follows: Group A > Group B > Group C and Group A > Group D. If a catalog item is shared with an Edit access level with Group A, all child groups (Group B, Group C, and Group D), receive an Edit access level on the shared catalog item.

    The group Organization also gets an Edit access to this catalog item because of the oversight, as explained in the previous section. If you know that certain assets (for example, terms) need to be shared with everyone, you can share them with the Organization (top parent group).

    Inherited access example two

  • Sharing can further be controlled by setting up isolated groups and branches (groups and their children). When a group is isolated, members of the group or branch are restricted from sharing assets and assigning stewardship to assets outside of their group or branch. For more information, see Groups, Group isolation section.

    In the following example, we have set the Europe group to be isolated, which is passed down to the child groups Sales EMEA and Marketing EMEA. The previously explained concepts related to sharing still apply, the only difference is that members of the Europe branch can only share and assign stewardship within the isolated branch.

    This means that members of Sales EMEA can share assets with members of Europe, Sales EMEA, and Marketing EMEA but not APAC or the North America branch. Members of the isolated branch can also only assign stewardship of assets to groups within the branch.

    Note that the Organization group keeps access to all assets through the oversight mechanism, which remains unaffected. This also means that sharing with individual users who are members of parent groups of the isolated branch is still allowed. However, this does not apply to stewardship assignment or sharing with the entire group because it would result in passing access to groups outside of the hierarchy of the isolated group.

    The same would apply to the isolated group of Marketing NA and any potential child groups: * Members of Marketing NA can only share access to members of Marketing NA and, due to the oversight mechanism, to individual members of North America and Organization. * North America and Organization groups keep access to Marketing NA assets. * Members of Marketing NA can only assign stewardship to their own group.

    Members of groups that are outside of isolated branches are not restricted from sharing assets and assigning stewardship to the isolated group or any other.

    Take note of the following:

    • If a user is a member of two isolated branches, the user can share any asset within both unless stewardship is already assigned to one of the branches.

    • If assets were shared with users outside of a branch before the branch became isolated, these settings remain unaffected. Revoke access manually as needed.

    Isolated groups example

With preceding mechanisms in mind, we recommend that you avoid adding users to the top Organization parent group because these users would automatically get access to all entities shared with any child groups.

To prevent this, the best practice is to manage individual users in groups under the Organization parent group. You can use the Organization parent group if you need to share assets with the entire organization regardless of whether it contains any users as the access rights will be inherited.

For more information about groups, see Groups.

Sharing entities with inheritance

When sharing access with users or groups to data assets of entities with hierarchy (for example, the source entity has the catalog item, connection, and location entities as child nodes on the metadata model graph), keep in mind that:

  • If you share access with users or groups for a parent entity type asset, these users or groups automatically get the same access level on all assets that are child entities of the parent entity.

    For example, if you share access with a group to a Source A with Editing access, this group receives Editing access on all child instances of the source entity, such as all catalog items, connections, and locations of Source A.

    You can check all the descendants of any entity in the metadata model (check the node on the metadata model graph).

  • You can increase the access level to a specific child entity asset for a group or user. This requires creating an additional sharing record for this specific data asset.

    Additional sharing record

    When assets of both parent and child entities are shared with a group or a user, the highest access level between the shared ones is applied.

    For example, if you share a source with Group A with View metadata access and then share a specific catalog item of this source with Group A with Full access, the group receives this catalog item with Full access.

    However, if you share a source with Group A with Full access and then share a specific catalog item of this source with Group A with Editing access, the group still receives this catalog item with Full access.

  • You cannot restrict access to a child entity asset below the access level granted on its parent. The access levels of a parent and its child entities combine as a union, which means the highest level always applies.

    Access levels configured in governance roles combine the same way. Connections and locations cannot be restricted independently of their source.

    For example, if a governance role grants Full access on the source entity but only View metadata access on the connection entity, users with this role can still add and edit connections. The Full access granted on the source applies to its connections as well.

    To limit what users can do with connections or locations, lower the access level on the source entity instead.

Sharing notifications

When sharing an asset, notifications work as follows:

  • When you share a data asset with a user or make adjustments in the shared access levels, this user gets a notification about the changes.

  • When you share a data asset with a group or make adjustments in the shared access levels, all users in this group get a notification about the changes.

  • When you remove access for a user or a group, users do not get any notifications.

Manage access

Use the following sections to share or remove access from a group or a user, or to check which operations a user can perform on an asset and why.

Share access

When you’re sharing access, you can see the default access level as defined on the Access Levels tab of the entity (for example, View Metadata Access) next to the group or user name.

If the access level you want to assign is not available for the asset, you need to add this level to the entity configuration. For more information, see Access Levels, section Configure access levels on entities.

If the editing option is not available, it means the access is inherited from the parent entity. In that case, you can edit the access level only from the parent asset.

To share access or change the access level to a data asset for a group or a user:

  1. Go to the Overview tab of an asset.

  2. Select Share.

    share icon example

  3. Search for users or groups with whom you want to share access and add all that apply.

  4. Expand the list of access levels next to the group or user name and select the required access level.

    share access dialog

  5. Select Done to save changes.

Remove access

To revoke access from a user or group:

  1. Go to the Overview tab of an asset.

  2. Select Share.

  3. For all the required users or groups, expand the list of access levels next to their name and select Remove Access.

  4. Select Done to save changes.

Explain permissions

The Explain permissions report shows, for one asset and one user, which operations are allowed and which are denied, and which share, stewardship assignment, or governance role decides each of them. Use it when a user can’t do something they expect to, instead of having to trace asset sharing, stewardship, inheritance, and governance roles by hand. The report is read-only and does not change any permissions.

The Explain permissions action is available on every asset whose detail page you can open.

To open the report:

  1. Open the asset, for example, a catalog item, term, or source.

  2. In the three-dot menu in the upper-right corner of the page, select Explain permissions.

    The Why these permissions? dialog opens and explains your own access to the asset.

The Why these permissions? dialog for a catalog item

If you have the MMM_admin identity provider role, which is attached to the ONE Administrator governance role by default, you can run the report for any user. In Explain permissions as, search for and select the user. To return to your own access, clear the field.

Read the report

The report can be marked as follows:

  • Not visible to you: The user can’t see the asset. The sections about grants and operations are not shown, and the You are acting as section explains why no share reaches the user.

  • Administrator bypass: The user has the MMM_admin identity provider role and can perform every operation regardless of sharing and governance roles. Any grants shown in the report are what a user without the role but with the same memberships would get.

For grants that come through a group, the report shows whether the user’s governance role in that group restricts them:

  • Governance role restrictions: The governance role allows a lower access level than the share, so the share is reduced to that level. The operations removed this way are listed.

  • No governance role restrictions: The governance role does not list this entity, so the share applies in full.

  • No effective governance role restrictions: The governance role allows the shared access level or a higher one, so nothing is taken away.

Shares made directly to the user or to their identity provider role are not restricted by governance roles.

When you expand an operation in What you can do — and why not, a table lists all access levels configured on the entity and whether each of them grants the operation. The level at which the asset is shared with the user is marked (shared to you), and the level a governance role caps the user to is marked (your governance cap). The table shows what would have to change for the user to get the operation: a share at a higher level, a higher access level in the governance role, or a change to the access level configuration of the entity.

Troubleshoot access issues

  • A user can’t see an asset: As a user with the MMM_admin identity provider role, explain the permissions as the affected user. If none of the user’s groups or roles has the asset shared with them, share the asset with the user or with one of their groups.

    If the asset is shared with one of their groups but their governance role in that group restricts access below viewing, raise the access level of the governance role on this entity, or share the asset directly with the user.

  • A user has fewer permissions than the shared access level: In Where your access comes from, the grant shows Governance role restrictions. Change the access level of the governance role on this entity, or share the asset directly with the user.

  • An operation is denied at every access level: If the access level table shows that no access level grants the operation, add the operation to the appropriate access levels on the entity in the metadata model. See Configure access levels on entities.

Was this page useful?