Permission architecture - SysAdmin

Overview

There is a given set of permission keys (currently around 80), hardcoded into the censhare client applications. Any combination of these permission keys can be assigned to roles and any user will be granted the sum of permissions that result from his role-assignments. Many permission keys control the manipulation of items that are domain-specific (primarily assets, but also master data in the administrative area). Those permissions are granted individually for every item that is accessed by the user.

All permission keys that are required for a certain field of work are collected in a permission set, and then the permission sets are assigned to the roles. It is not possible to assign permission keys directly to a role. There are no exclusion rules ("all permissions, except...").

The assignment sequence is as follows:

Permission key > Permission group > Role

Permission keys

Permission keys describe single features. Permission keys are predefined as master data in the database and the behavior of the keys is hardcoded in the censhare client applications. Usually, the predefined permission keys need not to be altered. The keys are made accessible for editing in the master data section of the censhare Admin-Client though, to allow modifications to the display names of the keys, if desired. It is also possible to add new permission keys for advanced customization of server modules.

The IDs of the default permission keys must never be altered and default permission keys must never be removed from the list. There exist some dependencies between permission keys, which are some times tricky to understand.

Permission sets

Permission sets should be named by functional entities and combine individual permission keys. Permission sets are stored as regular data in the database and can be created, modified and deleted at any time in the running system. One permission set System Administrator with full privileges is predefined in the system upon delivery and can be removed if not required anymore. Typical permission sets could be:

• Basic privileges for everyone

• Notes feature read-only

• Notes feature read/write

• Notes feature for administrators

• InDesign privileges

• Picture archive read-only

• System monitoring

Best practices

A common mistake in setting up permission sets is to think too much in roles and load up the permission sets with a lot of individual permission keys. In the extreme, one permission set would resemble one role. The purpose of the permission sets is to keep the lists of individual permission keys manageable. A permission set would typically not contain more than 10 individual keys. Permission sets should also be seen as self-contained functional entities, which can mean that the same permission key shows up in many sets (the permission to check out assets might show up for example in the sets InDesign, Content Editor, Addresses). Overlapping permission keys across permission sets are no problem at all.

Roles

Roles should be named by responsibilities and combine individual permission sets. Roles are stored as master data in the database and can be created, modified, and deleted at any time in the running system. One role System Administrator with the permission set System Administrator is predefined in the system upon delivery. Typical roles could be:

• Administrator

• Layouter

• Editor

• Copy Editor

• Photographer

The permission sets that are assigned to a role can further be restricted to certain subsets of the global workflow states that represent production phases. Two workflow state assignments are allowed for each permission group: the first one specifies the concurrent range of production phases in which the user can fully execute his permissions, the second one specifies the concurrent range of production phases into which the user can set the workflow step.

The second restriction is usually set to exactly one better phase than the first one, allowing, for example, scenarios in which full asset access is granted to an editor in the creation phase, but only in read-only access after an asset has moved on into the copy-editing phase.

Finally, for a role to become effective, it is assigned to the user account and at the same time associated with one node each in both domain trees. There can be any number of permission constellations (role, 1st domain node, 2nd domain node) assigned to any user account.

All modifications to permission keys, sets, and roles take immediate effect, without the need to restart the system, manually activate the modifications or for the users to re-login. Be aware that improper settings can prevent users from accessing needed features or even logging into the system!