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.
|
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)
- Allow create assets (permission set)
- Readonly (role)
- Allow previews (permission set)
- asset_preview (permission key)
- Allow previews (permission set)
- Editor (role)
- root.Frankfurt.
- Readonly (role)
- Allow previews (permission set)
- asset_preview (permission key)
- Allow previews (permission set)
- Readonly (role)
- root.Munich. (domain)
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:
- no access for non-owners
- read only access for non-owners
- full read/write access for non-owners
A non-owner can:
See asset | Edit asset | |
---|---|---|
No access | no | no |
Read only | yes | no |
Full | yes | yes |
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:
Has permission:
Input
Output
user true/false user, asset domain true/false user, asset domain, workflow step true/false Can access if non-owner:
Input
Output
user, asset true/false Can checkout:
Input
Output
user, asset true/false It mixes permission key checks with the asset state, storage state, deletion state checks.