User group policies
Content Hub users can perform actions based on their access rights. These rights are granted based on the groups a user belongs to and the policies assigned to those groups. Each user group policy consists of one or more rules, with each rule determining the conditions under which group members have permissions to do something. Groups can also be assigned special privileges that allow members to perform high-level system tasks.
Changes to user group policies have a significant impact on the security model. We recommend that only experienced superusers make changes to user group policies.
The elements of a user group policy are detailed in the following table.
|
Element |
Description |
Example |
|---|---|---|
|
Rules |
A rule is a collection of conditions and permissions that are specified for an entity definition or for specific entities within it. |
You create a rule for Portal.Page that states that the Editors user group can read but not modify a portal page; however, they can Read, Create, Update, or Delete assets. |
|
Member security |
Member security is a specific level of security (Read or Write) that is defined for an entity definition member group and its members. You must secure a member for it to be available on the Member Security tab. |
The M.Asset entity definition contains the General group, and within this group is a Brand member. You assign Read and Write permissions to the Brand member. |
|
Privileges |
A privilege is the highest level of security setting and is reserved for system settings, the domain model, as well as the security model. |
To the Testers user group, you assign all privileges so that they are able to properly test system settings. |
Review the security best practices for recommendations related to the security model.
User group and policy combinations
When designing the access model, follow these recommendations on how to structure user groups and combine user group policies.
-
To grant access rights to pages, definitions, settings, and so on, create a set of policies, where these policies are not used for access to a market or other taxonomies. Don't include user roles from across various markets, divisions, or departments. Also, don’t try to define group-level permissions that are only intended for a specific user; instead, configure each group’s permissions based on the responsibilities of its members, and ensure each user is assigned to the groups appropriate for their role.
-
To grant access rights to a specific market or similar, create a set of policies that you can combine at the user group member level using the Apply all operator. This operator applies all rules that are present in the user group policy combinations.
When a user is a member of multiple groups, you can apply user group policies separately or combine them using the following operators:
-
Any - only one of the user groups needs to give the user permission to do the requested action.
-
All - all of the user groups need to give the user permission to do the requested action.
The following table provides examples of how different policies across two groups affect what the user can do based on the operator used to combine them.
|
User group 1 |
User group 2 |
Operator |
Result |
|---|---|---|---|
|
Update permission on assets of type images |
Update permission on assets of type videos |
Any |
User can update images and videos |
|
Update permission on assets of type images |
Update permission on assets of type videos |
All |
User can’t update any assets because an asset can’t be an image ánd a video at the same time. |
|
Update permission on assets of type images, and documents |
Update permission on assets of type videos, and documents |
Any |
User can update images, videos, and documents |
|
Update permission on assets of type images, and documents |
Update permission on assets of type videos, and documents |
All |
User can update documents (but not images or videos) |
An example of how user groups and user group policies are used to grant read-only access to watermarked assets is also available.