Security and Permissions
From KnowledgeTree Document Management Made Simple
Contents |
Introduction
One of the essential features of KnowledgeTree is the ability to control who can see and modify the documents it contains. Unlike version 2.x, which had a fairly simple permissions model, KnowledgeTree 3.* has a rich and flexible system that allows system administrators to create fine-grained permission allocations across the document management system (DMS).
Put more clearly: KnowledgeTree has a number of ways to ensure that the right people can see and do the right things with the right documents.
Permissions
Security in KnowledgeTree is permission driven: each action requires that the user has a certain permission before it can be performed. The standard permissions (from KnowledgeTree version 3.*) are:
- *Core: Read*: this permission controls who can see and download a document. A user who doesn't have this permission will not even be allowed to know that the document exists - searches and the browse view will not show documents and folders that the user does not have permission to see.
- *Core: write*: this permission controls a number of aspects about the document, especially relating to modifying the document and its metadata. Users with this permission can check-out/check-in a document, create a new document in a folder where they have this permission, and edit the metadata of documents.
- *Core: add folder*: This allows the user to create a new folder in this location.
- *Core: Manage Security*: Users with this permission can control the security of a given folder and its children. This allows them to edit permission and role allocations at that point.
- *Core: delete*: this allows users to delete folders and documents.
Each of these permissions is marked "Core:" which means that they are part of the standard set. Plug-ins and extensions can add and check permissions on documents and folders in KnowledgeTree in exactly the same way as they use the core permissions, allowing them to give the system administrator flexibility in their use.
How Permissions are Allocated
KnowledgeTree provides three tools for allocating permissions, each of which has an appropriate use:
- Direct Permission Allocation
- Workflow
- Dynamic Conditions
Direct Permission Allocation
The first tool for allocating permissions is Direct Permission Allocation: the System Administrator says that all users in group A have the permission "Core: Write" in this location. That is the simplest and most direct approach, and works for many different uses. Permissions assigned in this way are inherited by items below that location, unless an allocation closer to the item in question overrides them.
Workflow
The second tool is Workflow. KnowledgeTree has a powerful workflow system that allows the system administrator to apply processes to documents. For example: an "Invoice" type document might have a life-cycle consisting of creation, review, distribution, and finally payment. At each step, different users need access to different types of operations on that document, and in some cases users may not have any permissions and cannot see the document at all until a certain stage in the workflow is reached. To use this you need to ensure that the document in question is in the appropriate workflow, and that at each stage the permissions you want to control are listed as controlled. Controlled permissions ignore other assignments, and only allocate the permission to the users specified in the workflow. You could say that workflows are always 'closest' to the document in terms of permission allocation.
Dynamic Condition
The third, and most complex way to allocate a permission, is via a Dynamic Condition. A dynamic condition is essentially a Search. You can use any of the criteria available in the 'Advanced search' mode to configure it. Once you've created a condition (e.g. the file is an Image created by a certain user), you can use it to allocate a permission to a role or group when it matches a document. You can, in essence, say that any document matching this condition grants a permission to a group or role. Note that users who would otherwise have that permission *still have that permission*, and that workflow allocations override dynamic conditions.
Users, Groups and Roles
Groups
To make administering security and information about users easier, they can be allocated to one or more groups. Groups can in turn be nested in one another: this allows you to define 'supergroups' made up of various other, more manageable entities. For example, you could define various groups of users as managers in each of their various departments, and then create a 'managers' group, which automatically contains the members of each sub-group. Controlling who is a manager then only needs to happen at the department level, and access that must be granted to all managers is automatic.
Roles
The second abstraction for allocating permissions is Roles. 'Reviewer', 'Team Member', etc. are all good examples of roles. The key difference between roles and groups, however, is that Groups can be assigned to Roles on a location by location basis. If you assign permissions or actions to Roles in a workflow, you can then use that workflow anywhere in the site simply by assigning the appropriate groups to it in that location.
For example, in a publication workflow the steps may be:
- submit document
- review document
- publish document
In each of these states, the roles 'Creator', 'Team Member' and 'Reviewer' may have different permissions. Only the reviewer may be able to edit the document once its published, and any member of the team may be able to use the discussion tool while the document is under review. Only the submitter might see the document before it is submitted for review.
If you assign these permissions to groups directly in the workflow, then the workflow can only be used where those Group-allocations are correct. If you describe the permission allocation in terms of Roles, then you can re-use the workflow across all teams and reviewers at your site.
As a general rule, one should use Roles rather than Groups to allocate permissions, and use Role allocations to identify the actual groups involved. Naturally, this is not a hard and fast rule: certain groups may always have certain permissions (e.g. Managers, etc.) depending on what your particular needs are.
Unit and System Administrators, and the Administrator Mode
Two key tasks need to be performed by users with greater-than-usual security allowances:
- management of the core system configuration (e.g. creating users, groups, workflows, fieldsets, and,
- administering permissions
While administering permissions can be performed by any user with 'Manage Security' permissions, it is also possible for those permissions to be removed.
To ensure that the system functions correctly, Administrators are needed. These are normal users who have additional responsibilities in terms of the system. However, from time to time they also need to perform maintenance tasks that exceed their normal system usage - updating permissions in a confidential HR folder, for example.
Additionally, the core Administrator group is usually a network or systems administrator with numerous other responsibilities, and a certain amount of delegation is required to ensure that these users aren't overwhelmed by trying to manage the DMS. To this end, it is possible to create Unit administrators: users with the System Administrator ability to override permissions, but only in one section of the system. Unit administrators can not access the 'DMS Administration' module - they only have elevated privileges in their Unit.
These additional privileges are granted by means of 'Administrator Mode' - a mode in which the user which activated it effectively ignores the "Core: read" and "Core: Manage Security" permissions. This allows them to see all documents and folders, and change role and permission allocations. Clearly, this isn't the normal state - it allows users access to documents they would not normally be allowed to see - but it is necessary to prevent parts of the system becoming completely inaccessible.
del.icio.us
digg
reddit
facebook
stumbleupon
