System introduction | Software development

What is a good authorization concept?

Not every user who works with a planning system should also be able to see everything - let alone enter any changes. In order to specifically regulate who is allowed to see and edit what, an appropriate authorization concept is needed. How does such a concept work? And what are the challenges in implementing it? A brief introduction will shed some light on the subject.

Software systems for multi-project management are complex - at least behind the scenes on the technical side. A multitude of functions must be provided for planning individual projects, managing tasks, creating reports, to name just a few. At the same time, not just one user is working with it. No, typically there are dozens of users sharing all these functions and the data in the system, often working with it simultaneously and from different locations. And of course, the application should be "super easy" to use for everyone involved and have an excellent user experience, according to business requirements, of course.

Multi-user systems require an authorization concept

With this starting position, it is not surprising that the software system sought must have a flexible but also easily comprehensible authorization concept. What do we mean by this? In the context of a software system, an authorization concept is simply defined,

  1. which user
  2. to which data
  3. what kind of access.

This raises several questions of understanding that need to be explained. First of all, the user of the system must be identified by the system. This is also referred to as authentication. The user logs on to the system by saying who he is and the system asks him to prove it. This sounds complicated, but we do this several times a day by entering our username and a password for it into a login window. With the username I tell the system who I am, and with the password I provide the proof. This simple process is called authentication. If we want to bring a little more security into play, then we require a little more proof from the user, for example by asking them to type in an additional one-time code that the system sends to their mobile phone. This is where we then talk about 2-factor authentication. But this is not the topic here.

What are permissions anyway?

With the authentication, we now know who we have in front of us. But what is this user allowed to do in the system? This is where authorization comes in, i.e. the allocation of authorizations with regard to the data and functions contained in the system. Now it gets a bit more complicated (at least from a technical point of view). Basically, you define a basic set of authorizations (also called permissions ). From this pot you then assign a number of permissions to the user. So far so good. But what exactly is a permission?

This is the first major challenge in this topic. An authorization can be defined in many different ways. Some examples:

  • View a project
  • modify a task
  • generate a report
  • create a new user
  • assign an authorization

Just the last example shows that permissions even work recursively: We can define permissions which allow to grant further permissions.... But the first few examples are also interesting, because they show us that a permission usually acts on an object type (a project, a task, a report, etc.) and involves an action (view, modify, generate, etc.). So basically we can just list all the data object types in our system and take all the possible actions for that. Combinations of these then result in the basic set of authorizations. As simple as this is to write, it is complex in reality. Even simple data storage systems contain dozens of object types and many different actions are possible on them. Simply multiplying these sets leads to an explosion of possibilities. Add to this the fact that you would naturally like to grant permissions on individual objects (i.e. instances of object types). E.g. "change project X", not generally "change projects". This adds another dimension of complexity.

This plethora of permissions needs to be well structured in order to get a handle on it and keep track of it. What we can do, for example, is the following. Permissions can be related to each other in a tree structure. A permission B can be defined as a branch of a permission A. This way we express that if a user is allowed to do B, then implicitly he is also allowed to do A. Again a simple example: "B = modify a project" and "A = modify a task". So if a user is allowed to modify a project, then implicitly he should also modify all contained tasks. This can be done similarly with actions: "B = modify a project" and "A = view a project". Here, too, permission B implies permission A, i.e. if someone is allowed to modify a project, then he is also allowed to view it (clearly).

How does a user get his permissions?

So let's just assume that we have defined and structured the basic set of permissions and therefore know them. How do I now assign these to a user? At first glance, you could make a direct assignment. For example: "User Meier has the permissions B, D, E and H". This is easy to understand - but only because the example is so trivial. Again, the complexity lies in the sheer number of possible combinations. If we have dozens or even hundreds of users and many times more permissions, we have to deal with exorbitantly large permission tables. The overview is then guaranteed to be gone. The problem can be eliminated if you are satisfied with only a small basic set of permissions. But from experience we can say that every buyer of such software systems demands so much flexibility in terms of "controlling and monitoring access" that we need a better solution.

The better solution is the one that works with rollers . This approach dates back to the early 1990s and has proven itself in practice. It is used in many, if not most, data management systems. This approach is known as Role-Based Access Control (RBAC). The principle can be explained like this: We define different roles (e.g. project manager, portfolio manager, system administrator) and then assign permissions to these roles. Only then do we take the users and give them one or more roles. In this way, users get their permissions indirectly through their roles. This principle has the big advantage that I can handle the interaction between users and permissions more easily, especially in case of changes. And as we all know, there are often changes. So if I want to revoke the permission of project managers to change projects, I do this on the role "project manager". All users with this role then immediately have the changed permissions.

The right structure is therefore required

It is the vast number of possibilities to define authorizations and assign them to users that makes the issue so complex. However, with a sophisticated structure, i.e. a good authorization concept, we can meet this great challenge. The above explanations only scratch the surface of the topic and the simple example of the introduction of roles is by no means intended to give the impression that this is the last word in wisdom. It is a possible and good approach. What we have also not addressed here is the visualization of the whole system states and functionalities from the user's point of view. How can a system administrator easily maintain the users, roles, and permissions and always be sure that they have actually made the right settings? We will get to the bottom of this question in a future article and show how we solve this using PQFORCE. So stay tuned.



About the author

Managing Director INTRASOFT AG

Dr. Daniel Hösli is Managing Director and Lead Consultant at INTRASOFT AG, whose SaaS solution PQFORCE is the leading platform for agile, project-oriented business management. He has been involved in the development of project management systems on a daily basis for 15 years in a consulting and project management capacity - both organizationally and technically - and thus has the experience from countless contacts and tasks from a wide variety of companies and different management levels.

Don't miss out

With PQFORCE Insights you get our latest news, best practices, tips and offers delivered to you right into your mailbox.
We will only send you relevant, spam-free emails.
You can always unsubscribe with just a click.
Try it now