RFC: Proposal for Enhancing User Roles and Permissions through Role-Based Access Control (RBAC)

[4lm]

This RFC aims to gather comments on an aspect I first mentioned in issue #1042. This RFC is non-critical and does not require immediate action. However, delaying this discussion could incur significant costs. I believe the current user role and permission system lacks maturity, and the longer we wait, the more expensive future changes will become.

Here are my main issues with the current system:

• There is a mix-up of entities and responsibilities. For example, a user (human) can create and act as a company.
• There is no separation between a user of the system and their role(s) within it. For instance, the system tightly couples a single user to a single company account, which is problematic in a company with 100 people where 10 different individuals might fill administrative roles and need to interact with the system.
• As more roles appear in the future, the system increasingly relies on custom checks and balances instead of a more robust, error-resistant permission system.
• There is no core-level entity permission system. Permissions are manually (arbitrary) set and often implicitly checked and scoped to views and use cases and not derived from entities (business logic) which should model the system in a way to mirror the real world entities (systems). Using Domain Driven Design principles would be, in my opinion, a good fit here.
• Authentication and authorization coupled and spread around in the view and use case layer. Authorization should derive from group permissions, set in the entity (core layer) logic. Suggestion:

I propose introducing a role-based access control (RBAC) system with a permission system, groups, and group membership that fully adheres to Clean Architecture principles. As an example of implementing such a system (though without the Clean Architecture part), Django handles this topic well.

Steps to implement this:

1. Introduce a permission entity.
2. Introduce a group entity.
3. Introduce group permissions.
4. Define user roles by group membership.
5. Unlike other systems (e.g., Django), prohibit direct user-permission relations. This approach aligns well with classic ACL found in companies and organizations and also forcing us to clearly define roles (groups) and their permissions on entity objects.
6. Incrementally trim use cases and views to adhere to the new system.

I look forward to your feedback and suggestions on this matter.

[seppeljordan]

We actually would never want to allow a member to act as a company.

[4lm]

We actually would never want to allow a member to act as a company.

I agree; we should aim to prevent such situations. This RFC specifically removes the possibility of a worker account acting as a company while using the same password and email address under their control, which is currently allowed. I sense that we might be discussing different aspects here. Could you please elaborate on what you meant by your statement?

[seppeljordan]

As more roles appear in the future, the system increasingly relies on custom checks and balances instead of a more robust, error-resistant permission system.

Why would we anticipate more roles to be added to the system?

[4lm]

As more roles appear in the future, the system increasingly relies on custom checks and balances instead of a more robust, error-resistant permission system.

Why would we anticipate more roles to be added to the system?

Why wouldn’t you consider this? At the moment, the system is modeled quite simply because it hasn’t been shaped by real-world needs yet. Once we have workers and companies using the system in practice, different roles will become necessary due to the division of labor and the need for checks and balances.

In any organization larger than one person, it is unwise to grant a single individual complete control over everything, such as changing one email and, by this, taking over the company; purchasing goods and services with no proper oversight; deleting plans; hiring and firing workers; or paying workers (possibly themselves) a little extra. A single rogue individual could cause significant harm to the organization and negatively impact other workers greatly.

Moreover, if every account in a system has full rights, it significantly increases the attack vector. As products and services become more complex, proper planning by multiple people becomes essential. Therefore, we will then need roles like such as plan creation worker, consumption management worker, internal accountant worker, external audit worker, worker contract worker — roles that will interact with our system according to their specific responsibilities.

Using a role-based and group-based permission system is, in my opinion, essential for this project to evolve into something widely used and effective.

Perhaps we should further discuss what we envision for this project? For example, I found @sloschert’s comment in this issue quite interesting. If we aim to model a core accounting system for other systems to use as the clearing system, we should instead probably focus on creating a scalable backend system that can be hosted in a federated manner at world scale. But here, we also would need a proper access and permission system 😉

[seppeljordan]

I never said that I wouldn't consider this.

[4lm]

I never said that I wouldn't consider this.

Yes, I realize now that the first sentence in my text was poorly worded and might have implied that I was questioning your consideration of my suggestion 😔. That was never my intention. Originally, it said, “Why wouldn’t you?” in response to your “Why would we anticipate more roles,” post-processing my answer via AI made my sentence even worse (the version you read). In both instances, the “you” was meant to refer to the general public, not to you personally. “Why wouldn’t we?” might have been another option. However, the entire sentence was meant as a rhetorical introduction and isn’t crucial to my arguments. I would simply delete it as it’s not essential. The arguments in the following sentences are what I'm keen to discuss.

As English is not my native language, writing texts can sometimes be challenging for me. I assure you my intentions are positive, and I hope you can ignore this linguistic slip-up and continue to engage with the substantive points in my response. In the future, I will try to formulate my texts more clearly and concisely ❤️

[Amittai-Aviram]

I find this RFC compelling. What are the possible problems? The added complexity of the system?