| Fevzi Öztürk, Operations Director |
For many organizations, controlling access to content is one of PaperWork's most important features. For a PaperWork system administrator, one of the hardest tasks is designing the right access control model for that content.
The requirements for an access control model vary widely from one organization to another, and they also differ between departments within the same organization. The PaperWork system administrator's job is to design access permissions in line with the organization's security sensitivities without having a negative impact on the system.
In this article, we look at methods commonly used in designing an access permission model and at how a model should be evaluated to understand how "good" it is.
Access Permission Sets in PaperWork
The term access control model describes the design of users, user groups and access permissions for accessing objects in PaperWork (documents, cabinets, etc.). PaperWork uses Permission Sets to design the access control model. To decide on an access control model, you therefore need a good understanding of Permission Sets.
To understand Permission Sets better, it helps to explain the 3 basic concepts in a permission set. A permission set has 3 basic elements:
. User
. Object and
. Operation
User should be understood as a specific user or user group. In a role- or group-based access control model, User corresponds to a group or a role.
Object corresponds to any object in PaperWork to which the permission is applied, of the System type or derived from the System type. This object can be a cabinet, folder, document or workflow.
Operation corresponds to the operations the User can perform on the Object. The simplest and most intuitive operations are access, read, write and delete, but PaperWork defines many different Operations for an Object.
PaperWork's access control structure is based on permission sets. A permission set specifies the access permissions for an object. In other words, a permission set is used to define the [Operation] permissions of a [User] on an [Object].
A Permission Set is used to define the [Operation] permissions of a [User] on an [Object].
Every object of the System type, or any object derived from the System type, has its own permission set.
To better understand how an access control model is implemented with permission sets, it is worth looking at a few different examples we often come across in real life.
Example 1: A Small Number of Permission Sets
In this model, there are only a few permission sets, and they are associated with a large number of documents. If many documents are associated with one permission set, that permission set covers a large amount of content.
Example 2: Customized Permission Sets
In this model, there are many customized permission sets. Each permission set is applied to very few documents, and as the number of documents grows, so does the number of permission sets. The extreme case of this model is creating a separate permission set for every document. Such a model is usually seen when access permissions are applied to documents through other software or workflows.
Example 3: A User Belongs to Many Groups
In this model, some user groups are associated with all documents. When some users need access to all documents, they are added to all the groups. The result is a model in which a single user belongs to hundreds or even thousands of groups.
These are just a few examples of access control models that can be implemented with permission sets. Combinations of users, user groups and operation permissions can produce many different access control models.
If the access control model you designed causes problems in your implementation, there are very few changes you can make to the model or the implementation without compromising the access security you need. Testing your access control model continuously and regularly against your requirements before you finish implementing it, or worse, before going live, so that you can identify gaps and make the necessary changes, will save you from many problems in the long run.
So how can you tell whether the access control model you designed for your implementation is a good one?
Evaluation Criteria for an Access Control Model
When evaluating how "good" an access control model is, it is worth paying attention to the points below.
Because users, user groups and access authorization needs change over time, permission sets also need to be updated. The management of these changes should be considered when creating permission sets. These changes usually require administrative operations such as:
. Removing a user's access permissions when they leave the company
. Giving a new user permission to access documents
. Changing a user's permissions
An access permission model with customized permission sets for every document, as in Example 2, is extremely hard to manage. When access permissions change, a very large number of permission sets must be modified. That is why having a large number of permission sets makes for a permission model that is hard for system administrators to manage.
Having many users or user groups in a single permission set makes it harder to update. The PaperWork permission set management screens may not be very practical when there are a large number of users or groups.
Conclusion
Above, we covered a few common access control models that can be implemented with permission sets. However, many other models can be built with different combinations of User, Object and Operation elements, and it is very hard to know all of them.
As PaperWork is used and the numbers of users, documents and workflows grow, any access control model you implement may run up against certain limits. So when planning the access control model, you should consider which limitations you might encounter. For example:
In a model that uses customized permission sets, as in Example 2, you may end up with millions or even billions of permission sets.
In a model where users belong to many groups, as in Example 3, users may end up in hundreds or even thousands of groups.
A model may end up with thousands of users in its permission sets
A model may end up with thousands of users in a single group
With the possible situations above in mind, you should consider what limitations the access control model will face and what management challenges it may create while designing it.
There are many ways to design an access control model, but it is impossible to define best practices that apply to all models. To evaluate how good or correct an access control model is, you can follow the approach suggested below.
. Assess what limitations your access permission model may face over time.
. Simulate your access control model with information and content as close to the real environment as possible.
. Identify the functions users and system administrators need to do their work, and test your access control model against these functions.
Sources
https://www.ibm.com/think/topics/identity-access-management
https://www.ibm.com/think/topics/rbac
https://dergipark.org.tr/tr/download/article-file/76515
Would you like to see PaperWork in your organization?
Request a Demo
