Understanding user access and permissions

Impersonation

Impersonation is useful for checking how the user interface appears to a specific user and what entities they can access.

You can impersonate a user by clicking Manage > Users > Users > View details > Impersonate, and then confirming that you want to impersonate them. To exit impersonation mode, you can do any of the following:

• Remove cookies for the site and refresh the webpage
• Log out and then log in again as superuser.

Security diagnostics

As an alternative to impersonation, the security diagnostics tool is useful for checking the exact permissions a user has for a specific entity (asset or content item), including which user group grants each permission and through which inheritance chain.

Accessing areas of the user interface

Modules alone do not guarantee access to an area of the user interface. For a user to access a page, all the following must be true:

• The required module must be available in your license.
• The required module must be assigned to the user's account.
• The user must be a member of a user group whose policy grants Read permission on that specific Portal.Page entry.
• The page must be visible.

If any of these conditions is not met, the user does not see the menu bar item or the pages inside it. For example, if you add a user to a group with read permissions on assets and collections, but the user does not have the Media module assigned, they cannot access the Assets and Collections pages.

The conditions listed above are sufficient to make the page visible and navigable. For users to see data on the page, such as assets in a search result, they also need Read permission on the entity definitions that the page displays.

Modules and user groups

Note the following behavior when assigning modules through user groups:

• Modules assigned to a user group are automatically assigned to new users added to the group, but not to users who were already in the group before the module was assigned. You must assign the module to existing members individually or by using mass edit.
• Removing a user from a user group does not remove the modules that were assigned to them when they joined the group.
• Removing a module that was previously assigned through a group does not remove the user from that group.

User group policy

A key element of a user group is the user group policy. Every user group has a policy. Every policy consists of rules, member security, and privileges, which combine to determine the user's access rights.

Rules and conditions

When you configure a user group policy, you start by creating a rule within the policy. A single user group policy can contain multiple rules. By default, a rule applies to all entities within the scope of the rule. To granularly control which entities the rule applies to, you can add conditions to the rule. A single rule can contain multiple conditions.

Additive permission model

Content Hub uses an allow-only permission model. Every rule in a user group policy is a grant, and there is no rule type that blocks or removes access.

Because there is no deny mechanism, you cannot restrict access by adding a rule to a user group. Adding a rule can only grant additional access. Therefore, to prevent a user from accessing something, ensure that none of the groups they belong to grant that access.

To restrict a user's access, you must do one of the following:

• Remove the user from the group that grants the unwanted permission.
• Remove the permission from that group's policy. This affects all members of the group.

The additive permission model applies directly to what users see in the user interface. If a user has Read permission on a page and satisfies the other conditions for accessing the page, that page and its navigation icon, if any, are visible to them. If you want to hide a page from a user, ensure that none of the groups the user belongs to grant Read permission on that page. For an example scenario, see the Preventing access to the Manage area.

How inheritance works

When Inherits security is enabled on a relation, an entity inherits the security context of the entities it is related to through that relation. Content Hub uses this inherited context when evaluating whether a user has access to an entity.

For example, consider a Product entity that is related to a ProductStatus entity through the PCMProductStatusToProduct relation. If Inherits security is enabled on that relation, the product inherits the security metadata of its status. A user group rule that grants permissions on products in the Created status can then correctly evaluate whether a specific product qualifies.

If Inherits security is not enabled on the relation, Content Hub cannot traverse it to evaluate the condition. The rule is configured correctly, but it never matches any entity — and no permissions are granted.

Collections and assets

Collection permissions and asset permissions are always evaluated independently. Granting a user access to a collection does not automatically grant access to the assets inside it.

That is because the CollectionToAsset relation has Inherits security disabled by default. This means:

• A user who can read an M.Collection entity cannot automatically see the assets within it.
• To grant access to assets in a specific collection, you must separately grant the user Read permission on the M.Asset definition. You can scope this to the relevant collection by using a shared taxonomy category that links both the collection and its assets.
• The User Access control on a collection's detail page grants access to the collection entity itself only. It does not grant access to the assets inside the collection. To give those users access to the assets, you must also configure the appropriate M.Asset permissions in their user group policy.

Multi-level inheritance

Inheritance is transitive. If entity A inherits security from entity B through one relation, and entity B inherits security from entity C through another relation, then entity A may also inherit security from entity C.

In schemas with multiple relations that have Inherits security enabled, this can result in users accessing entities they were not explicitly granted access to. For example, a user with access to a specific brand may unexpectedly gain access to features, series, or special offers linked to that brand through a chain of inherited relations.

Use the security diagnostics tool to trace the permission chains for any entity and verify which user group and which inheritance path is granting access. If access is broader than intended, disable Inherits security on intermediate relations that are not required for your permission conditions.

Enabling Inherits security on a relation

To enable Inherits security on a relation:

1. Go to Manage > Schema and open the entity definition that contains the relation.
2. Find the relation member you want to configure.
3. Open the relation's Advanced tab.
4. Enable Inherits security.
5. Click Save.

After enabling the flag, clear the cache to ensure the change takes effect immediately.

Conditions on direct members

When a condition is based on a member that belongs directly to the entity definition (for example, a taxonomy tag on an asset), no additional configuration is needed. Content Hub evaluates the condition against the entity's own data.

Conditions on related entities

When a condition is based on a related entity (for example, filtering products by their status through a relation), the Inherits security flag must be enabled on the relation connecting the two entity definitions. Without it, Content Hub cannot walk the relation to evaluate whether the condition is satisfied, and the rule silently has no effect.

This is a frequent source of misconfigured permissions. If you configure a rule with a relation-based condition and the expected access is not granted, check whether Inherits security is enabled on the relevant relation before troubleshooting elsewhere.

Constraints

• Permissions are always additive. Conditions narrow the entities a permission applies to, but they cannot deny access. If another rule in any of the user's groups grants the same permission without conditions, that rule takes precedence and the user retains the broader access.
• When using a taxonomy condition, include all relevant taxonomy values. Because Update is validated against both the current and future state of an entity, if a value is missing from the condition, users cannot update entities to or from that value. For example, if you include only Poster under M.AssetType, users cannot edit assets tagged as Artwork. For more information, see Configure a user group policy.
• The special Only entities created by current user option is also a condition. When selected, the rule applies only to entities the current user created, in addition to any other conditions on the rule.

Combining permission layers

Consider a user called Demo.Photographer who should only see their assigned tasks on the Tasks page. To achieve this:

• The user is assigned the Project module.
• The user is a member of the W.Photographers user group, which grants Read permission only on Portal.Page definitions.
• The user is a member of the Everyone user group, which assigns the minimum permissions required by a user in Content Hub, and the M.Builtin.Project.Everyone user group, which grants Read permission on pages related to projects, tasks, and jobs.
• The user has no project roles assigned.

Together, these layers give the user access to the Tasks page and the tasks assigned to them, without exposing any other content or features.

Preventing access to the Manage area

Consider a scenario where you want to prevent a user from accessing the Manage area. Because permissions are additive, you cannot configure a rule to hide the Manage area. Instead, review the portal page permissions in the policy for every user group the user belongs to and include only the pages the user needs access to.

To do so:

1. Review all groups the user belongs to. Any Read permission on the Manage page granted by any of these groups gives the user access to the Manage area. Identify and, if appropriate, remove those permissions.

   The out-of-the-box Superusers group provides access to the Manage area by default. Other out-of-the-box groups, including the Everyone group, do not provide access to the Manage area by default.

2. In the user's user group policy, create a rule for Portal.Page, add a Portal.Page condition to it, and click Select to choose items for the condition. In the Select items modal, select only the specific portal pages the user needs, for example, the Assets search page and the asset detail page. Grant Read on these pages only. Do not select the Manage page.

3. Test the affected user's access to verify they cannot access the Manage area.

Controlling access to assets

Consider a scenario where you control a user's access to the Assets page. This user already has the Media module assigned, so they can see and click the Assets item in the menu bar. This user is currently only a member of the Everyone group, so clicking Assets loads an empty page with no assets available. To let the user view assets, you need to give them Read permission on both the asset data and the Assets portal page.

To do that, you create a new user group and add the user to it. In the group's policies, you create two rules:

• For rule 1, add Asset (M.Asset) and enable Read. This grants access to the asset data.
• For rule 2, add Portal page (Portal.Page), set the condition to Portal.Page: Assets (and the asset detail page), and enable Read. This makes the page visible in the menu and navigable.

After saving your changes, the user can view all available assets on the Assets page. That's because neither rule has conditions: each rule applies to all entities in its scope.

You can granularly control which assets the user can view by adding a condition to a rule. For example, add a condition to rule 1 based on Asset media (M.AssetMedia), click Select, and choose docx and mp4. Confirm your choice and save your changes. The user now has access only to DOCX and MP4 assets.

If you add a second condition to rule 1, for example, Geography: Canada, both conditions must be true for an asset to be accessible. The user can now only access DOCX or MP4 assets where the geography tag is set to Canada.

Restricting access by a related entity

Consider a scenario where you want users in the ABC.Product.Creator group to only be able to update products in the Created status.

You create a rule for Product (M.PCM.Product), add a condition for M.PCM.ProductStatus: Created, and enable Update and Delete. You test the result, but editing controls do not appear for the user, even on products that are in the Created status.

The cause is that the PCMProductStatusToProduct relation does not have Inherits security enabled. Content Hub cannot traverse the relation to check the status condition, so the rule never applies.

To fix this:

1. Go to Manage > Schema > Product (M.PCM.Product) > Edit .
2. On the Commercial tab, find the PCMProductStatusToProduct relation member and click More actions > Edit .
3. In the Edit member modal, on the Advanced tab, enable Inherits security, and click Save.
4. Clear the cache.

After this change, the condition evaluates correctly and users in ABC.Product.Creator can update and delete only products in the Created status.

Granting access to assets within a collection

Consider a scenario where you want users in the collectionTest user group to see the assets inside a specific collection.

You grant Read on the M.Collection definition for the collection, add the user to the group, and the user can see the collection on the Collections page. However, when they open the collection, it appears empty.

The cause is that collection permissions and asset permissions are evaluated independently. The CollectionToAsset relation has Inherits security disabled by default, so read access to the collection does not cascade to the assets inside it.

To resolve this, you must separately grant the collectionTest group Read permission on M.Asset. To scope access to only the assets in that specific collection, rather than all assets, use a shared taxonomy category:

1. Go to Manage > Taxonomy > New taxonomy, and create a taxonomy, for example Category.
2. On the Taxonomy Management page, click Add to add an item, such as Category A, to the taxonomy.
3. Create relation members to link M.Collection to Category and M.Asset to Category, with Inherits security enabled on both.
4. Assign the collection and its assets to Category A.
5. In the collectionTest group policy, add a rule for M.Asset with the condition Category: Category A and enable Read.

Users in collectionTest can now see the assets in that collection, scoped to only those tagged with Category A.

Granting read-only API access to assets and public links

Consider a scenario where you want to connect a reporting platform to Content Hub using a REST API. The platform needs to read all assets and their associated public links to generate a report, but must not be able to create, modify, or delete anything.

Create a new user group, such as API.ReadOnly, and open its policies. Add two rules:

• For rule 1, select Asset (M.Asset) and enable Read. Do not add any conditions.
• For rule 2, select Public link (M.PublicLink) and enable Read. Do not add any conditions.

Because neither rule has conditions, each applies to every entity in its definition. This means that all assets and all public links in the system are readable by members of this group.

You do not need a third rule for the AssetToPublicLink relation because in Content Hub, permissions are defined on entity definitions, not on relations. When a user has Read permission on both M.Asset and M.PublicLink, the AssetToPublicLink relation between them is automatically traversable via the API.

Because this group is for API access only and does not require browser UI navigation, you do not need a Portal.Page rule. Portal page permissions only control what a user sees in the Content Hub interface. If the integration account also needs UI access, add a rule for Portal page (Portal.Page) following the approach described in the Controlling access to assets example.

Finally, create a dedicated service account user for the integration and add it to the API.ReadOnly group. That account now has read access to all assets and public links across the system, with no write capabilities of any kind.