Permissions overview

Overview of the censhare permission and access control mechanism.

Permissions

A permission key controls the execution of a feature. The list of permission keys is fixed and the behavior is hardcoded.

Permission checks are included into command execution methods. Usually, an exception is thrown if the required permission is missing.

if (!permService.hasAssetPermission(KEY_APP_LAYOUT_EDITOR_ALL, asset)) {
    throw new LayoutEditorException("No permission to change the template of the document");
}

Currently, there are more than 100 permission keys. For a detailed overview, see the Permission key table in the Master data section in the censhare Admin Client.

Example:

• key: asset_edit_attributes
• name: Edit asset attributes
• description: Allows editing of asset attributes

Domains

Assets and Users are associated with domains. Domains form a hierarchical collection of nodes (a tree).

A user can only see the assets that fulfill one of the following conditions:

• belong to a domain node assigned to the user
• belong to any descendant node of an assigned domain node

Connection between User and Permission keys

Permission keys, that are required for a certain area of work, are collected in a permission set. The permission sets are then assigned to the roles.

User -> Domains -> Roles -> Permission sets -> Permission keys

Permission sets in a role can also depend on the workflow steps.

Example:

• Paul (user)
  • root.Munich. (domain)
    • Editor (role)
      • Allow create assets (permission set)
        • asset_checkin_new (permission key)
        • asset_edit_attributes (permission key)
      • Allow picture editor (permission set)
        • app_pictureeditor_all (permission key)
    • Readonly (role)
      • Allow previews (permission set)
        • asset_preview (permission key)
  • root.Frankfurt.
    • Readonly (role)
      • Allow previews (permission set)
        • asset_preview (permission key)

Structure of the permissions

Ownership

Ownership checks are independent from permissions and domains and are applied separately.

The ownership also restrict the ability of a non-owner user to see or edit an asset.

There are 3 options:

1. no access for non-owners
2. read only access for non-owners
3. full read/write access for non-owners

A non-owner can:

API

Ownership and domain determine if a user can see an asset or not. Then, permissions are applied to find out what the user can actually do. The decision is based on the user, but also the asset and the workflow step might be taken into account.

The permission services methods can be divided into 3 groups:

1. Has permission:

   |Input|Output| |:---|:---| |user |true/false| |user, asset domain|true/false| |user, asset domain, workflow step|true/false|

2. Can access if non-owner:

   |Input|Output| |:---|:---| |user, asset|true/false|

3. Can checkout:

   |Input|Output| |:---|:---| |user, asset|true/false|

   It mixes permission key checks with the asset state, storage state, deletion state checks.

Last Updated: 27 November 2019