Role-Based Access Control (RBAC) #95

cbbayburt · 2024-11-12T13:06:45Z

This RFC proposes Role-Based Access Control (RBAC) model in Uyuni.

accepted/00000-rbac.md

Etheryte · 2024-11-12T14:51:47Z

accepted/00000-rbac.md

+### Performance
+
+Access control checks query the database on every request.
+To mitigate performance impact, a user's access rules can be preloaded into memory and stored in the user's session data during login, enabling faster access control validation.


Small issue: if the rules that apply to a user change while they are logged in, this will lead to a mismatch, how will we address that?

As first step I think we should not cache any information. We can change that if we notice any performance issue. The topical (as most simple) solution for this kind of situation is that the user must logout and login again.
Another option is to check which sessions are active in the database for user affected by the access change an invalidate those authentication sessions.

I agree. But when we decide to implement caching, I think safest and easiest solution would be to simply kick the user out and require a new login whenever their permissions change. This shouldn't happen often anyway.

Etheryte · 2024-11-12T14:55:10Z

How do we plan to integrate all of this with the frontend? If a user does not have W on a resource, it doesn't make sense to show them UI components that will just throw an error when they try to save changes. So we would also need to make this information available to the UI in some manner and enforce checks there as well for usability.

rjmateus · 2024-11-12T16:50:16Z

How do we plan to integrate all of this with the frontend?

@Etheryte In my opinion that is a good usability improvement but should be considered a second step. With this RFC we want to set the foundations in term of authentication and changing all the pipes to make it more robust and configurable. As next step I think we can improve a lot the UI, and make it more tailored to the end user.

aaannz

IIUC, this RBAC implementation will not help with something like proxy admin seeing only systems below that proxy, right?

Visibility will still be based only on organization level, correct?

aaannz · 2024-11-12T21:02:18Z

accepted/00000-rbac.md

+
+1. **Authentication:** Identifies the user calling this action.
+2. **Authorization:** Determines if the user is allowed to call the endpoints for this action.
+3. **Accounting:** Assesses whether the user is permitted to operate on a specific entity.


Maybe it is my bad English, but are you sure Accounting means this? Everywhere I looked, accounting is about measuring, logging etc.

From the sentence in the RFC I would assume accounting is some action which can block user access.

This is a concept in user access control called Authentication, Authorization, and Accounting (AAA)
Here some links talking about it:

https://community.fs.com/encyclopedia/aaa.html

https://info.support.huawei.com/info-finder/encyclopedia/en/AAA.html

https://www.strongdm.com/blog/aaa-security

I'll try to rephrase this to be more clear

IIUC, this RBAC implementation will not help with something like proxy admin seeing only systems below that proxy, right?

Visibility will still be based only on organization level, correct?

This actually refers to "Accounting". No, at this point we won't control access at this level.

Well not according to those links @rjmateus provided. Accounting is according to those links:

Accounting, the final process in the framework, is all about measuring what's happening within the network. As part of the protocol, it will collect and log data on user sessions, such as length of time, type of session, and resource usage. The value here is that it offers a clear audit trail for compliance and business purposes.

Accounting Accounting records the used service type, start time, and data traffic to collect and record the network resource usage of the user for implementing time- or traffic-based accounting and network monitoring.

So to me this sound like Accounting it measuring and logging and no way it can decide user has access to this or that. It is simple passive step of logging.

So the "visibility" of resource should be part of Authorization step.

But as we do this RBAC over API calls and not over resources, I guess there is no way to limit user access to individual machines.

User has access to system/listSystems API call and thus can list all systems of given organization (assuming organization visibility will remain).
User has write access to system/deleteSystem and thus can remove all systems of given organization.

And now I'm trying to figure out from where I read that statement :-|
And you are completely right, Accounting is the process of recording all the user interactions.
Currently access control to machines have a different process on SUMA, and relies on 2 roles (spacewalk admin and organization admin) and also if a user is assigned to a systems group.
This is something we can refactor, but in my opinion should be a different step.

@aaannz thank you for pointing it out. Resource access should be one step of the Authorization process. However, This RFC is focusing only at the part ...perform operation O.... This would be already a big step, since the role/access control is spread across all the code (from API definition, to database access factories), and this is something we must clean.
Next step can be find a better way to perform resource access check. What do you think?

Sorry, it seems I mixed up all the terms. I rewrote the part so it's hopefully clearer now.

aaannz · 2024-11-12T21:12:02Z

accepted/00000-rbac.md

+Every access point in Uyuni is mapped as an **endpoint** in the database and grouped into **namespaces**.
+Access control is enforced by defining rules for these namespaces, either per **user** or **access group**.
+
+Below is a simplified ER diagram illustrating the proposed structure for access information in the database:


I know we are not discussing implementation details here, but seeing the ER diagram I can't help myself.

Please NO NUMERIC IDs, I can't stress this enough.

Use BIGINT with identity generated always. Exception being already existing IDs.
And btw. VARCHAR is the same as TEXT in postgres, so use TEXT everywhere.

Noted. Thanks for the tip.

cbbayburt · 2024-11-13T11:57:01Z

How do we plan to integrate all of this with the frontend? If a user does not have W on a resource, it doesn't make sense to show them UI components that will just throw an error when they try to save changes. So we would also need to make this information available to the UI in some manner and enforce checks there as well for usability.

@Etheryte the new mechanism will provide means to check information regarding access rules to use on any page to show/hide/disable sections. You'll be able to check if the user has access to something and render that part conditionally.

The hardest part is to do this on all the existing pages. We have to keep this out of scope to make it feasible for 5.1. Until then, when the user navigates to some disallowed part, we'll simply return a branded 403 page.

Once the RBAC is done, we'll have to go page-by-page to add conditions according to the user's access rules.

With the initial implementation though, we'll at least hide the disallowed entries from the left menu bar.

If we can find the time, we can also do this for important parts, like hiding disallowed system details tabs, etc.

rjmateus

Looks really good Can. Just some small clarification, otherwise looks great to me.

rjmateus · 2024-11-13T12:10:45Z

accepted/00000-rbac.md

+
+## Overview
+
+This solution stores all available network endpoints in the database and determines which endpoints each user can access, with the exception of the **Uyuni Administrator** role, which bypasses access control.


Suggested change

This solution stores all available network endpoints in the database and determines which endpoints each user can access, with the exception of the **Uyuni Administrator** role, which bypasses access control.

This solution stores all available system endpoints in the database and determines which endpoints each user can access, except the **Uyuni Administrator** role, which bypasses access control.

rjmateus · 2024-11-13T12:17:01Z

accepted/00000-rbac.md

+- **`endpoint`**: The accessible URI of the endpoint.
+- **`class_method`**: The Java class that handles incoming requests to the endpoint, such as a controller class for web endpoints or an API handler for API endpoints.
+- **`http_method`**: The HTTP method (e.g., GET, POST, PUT, DELETE) accepted by the endpoint. If multiple methods are supported, each should be defined as a separate endpoint since they typically serve different purposes.
+- **`scope`**: Indicates whether the endpoint is accessible through the web UI (including internal API calls) or the public API.


I think we should add 2 more fields to the table, one expressing if the endpoint needs authentication and another if authorization is required.
In the PoC this was implemented as a static list on Java side, but I think we could move this information to the database.

I'll add a auth_required column to the RFC to exclude the URLs outside of authentication space (like login, about, API docs, etc.).

I'm not 100% sure about the second flag. It may or may not be needed, depending on the details of the implementation. So I'll leave it out for now.

rjmateus · 2024-11-13T12:18:48Z

accepted/00000-rbac.md

+
+  For example, `clm.project.details` **[R]** allows viewing a project's details, where `clm.project.details` **[W]** allows modifying them.
+
+- **`description`**: A clear description of what a namespace grants access to.


I think we can also add a flag to define if the namespace is tailored to be used from the Web application side of API (XML-RPC side), similar of what we have in the endpoint. I know we can play around with the namespace prefix, but this way would be more explicit.

rjmateus · 2024-11-13T12:19:55Z

accepted/00000-rbac.md

+
+- **`label`**: The label of the access group.
+- **`description`**: The purpose or scope of the access group.
+- **`org_id`**: The ID of the organization to which the group belongs. This field will be `null` for predefined groups.


This "vendor" groups cannot be changed by the users.

rjmateus · 2024-11-13T12:26:48Z

accepted/00000-rbac.md

+
+#### Existing roles
+
+To ensure a smooth transition, existing roles will remain until all JSP/Struts pages are fully removed. The new access control mechanism includes default user access groups replicating the following roles:


I'm not sure about this topic. We must create access groups mapping the existing roles, that is a must.
However, some of these roles need to stay around for a longer time, even if we remove struts, since they grant access to data and not just features: "Uyuni Administrator" and "Organization administrator" (not 100% sure about the remaining).
For the ones that don't grant access to data, we could try to remove them. The part that can be tricky is the struts ACL rules, which may stop working properly.

An alternative solution for the roles that don't grant data access, and avoid touching the struts ACL could be assign those roles to all users, since the access control to the features will happen in the next mechanism.

We also must develop a automatic migration mechanism from the old roles to the new user access groups.

What do you mean by data access?

An alternative solution for the roles that don't grant data access, and avoid touching the struts ACL could be assign those roles to all users, since the access control to the features will happen in the next mechanism.

Yes, the problem is that the current access control with static roles is embedded everywhere (React as well) and trying to remove these is going to cost a lot of time. So instead, my plan is to leave them in, hide them from the UI (replaced by the new ones), and assign all these static roles to every existing and future user so they effectively won't do any access control.

However, I'm wondering if we should keep an unrestricted bypass mechanism in the filters for the Uyuni and Org Admin roles like:

public boolean canAccess(User user) { return (user.hasRole(RoleFactory.ORG_ADMIN) && user.getOrg().equals(getOrg())) || user.hasRole(RoleFactory.SAT_ADMIN); }

or should we rely on RBAC only? Are there some areas that won't be covered by RBAC?

You can try in the existing implementation. If a user is part of organization and has not roles, and are not assigned to any systems groups, then the user cannot see any system. If the user has the role Org Admin, then it can see all the systems that are part of that organization.
So currently, the roles are not just to control access to pages but also access to data. I can show you tomorrow.

Oh ok now I get it. So those superuser logic must stay in the new implementation in any case. All the others can go once we're ready to strip their logic from the individual pages.

rjmateus · 2024-11-13T12:33:26Z

accepted/00000-rbac.md

+After the initial development and mapping of all existing endpoints to the new structure, ongoing effort is required to keep endpoint mappings and the namespace structure up-to-date. To reduce RBAC overhead when implementing new features, the following additional resources are proposed:
+
+- An extensive Wiki guide on adding necessary endpoints with proper namespace organization
+- Stored procedures and scripts to easily grant/revoke user access for development


I would prefer to avoid store procedures as much as possible. They are hard to test and are hidden inside the database.

I agree. These will be just throwaway tools to help when we're implementing RFC. There's no plan to ship or persist them. Once the API is in place, they won't be needed anyway.

accepted/00000-rbac.md

rjmateus · 2024-11-13T12:35:48Z

accepted/00000-rbac.md

+# Unresolved Questions
+[unresolved]: #unresolved-questions
+
+- **Granularity of access control:** Should the RBAC model include finer-grained permissions, such as access by specific actions (create, update, delete) within a namespace, or is the proposed "View" vs. "Modify" access mode sufficient for most cases?


In my opinion, whenever its possible we should have as fine grain as possible, with a separation between the create, update, delete, for example.

rjmateus · 2024-11-13T12:37:03Z

accepted/00000-rbac.md

+
+- **Granularity of access control:** Should the RBAC model include finer-grained permissions, such as access by specific actions (create, update, delete) within a namespace, or is the proposed "View" vs. "Modify" access mode sufficient for most cases?
+
+- **External integration needs:** Will the RBAC system require compatibility with external authentication or access control systems, such as LDAP, and if so, what integration points are required to support this?


That I would say is part of authentication. However, we could define a mapping between LDAP user groups and suma internal access groups, and automatically assign users to a group at login time.

rjmateus · 2024-11-13T12:38:24Z

accepted/00000-rbac.md

+
+- **External integration needs:** Will the RBAC system require compatibility with external authentication or access control systems, such as LDAP, and if so, what integration points are required to support this?
+
+- **Additional access groups:** Should predefined access groups be expanded to cover specific use cases beyond those mirroring existing roles?


That is something we will find out, and we can react according to feedback from customers. One extra groups could be the read-only user that we have now for API only. that can be a new access group and stop relying on method names and a flag on user definition.

Etheryte · 2024-11-13T17:10:56Z

Also a small ping for @thesp0nge, if you have the time to give this a read, any input you might have on this proactively would be much appreciated.

thesp0nge · 2024-11-13T17:14:01Z

I'm sorry but for such kind of requests you really want to ask @szachovy , your security champion.

cbbayburt · 2024-11-13T17:54:59Z

@Etheryte @aaannz @rjmateus, all the discussions should be addressed now. Please let me know if there's something I missed.

Etheryte

From my side this looks good, I think this is high level enough that most of the detailed discussions will happen in the specific implementation parts later.

cbbayburt · 2024-11-13T18:36:03Z

From my side this looks good, I think this is high level enough that most of the detailed discussions will happen in the specific implementation parts later.

Thanks for the review, Karl. Yeah I think this level of detail should be enough to get everyone on the same page and make the right decisions from the beginning so we won't have to scratch the whole design.

rjmateus

Looks good to me. Thank you for preparing it

szachovy · 2024-11-14T17:03:19Z

accepted/00000-rbac.md

+# Drawbacks
+[drawbacks]: #drawbacks


Spacing throughout the document is inconsistent, can you parse it through https://github.com/DavidAnson/markdownlint ?

admd

Only done have way through. I have Left some questions for my understanding.

admd · 2024-11-15T13:25:25Z

accepted/00000-rbac.md

+
+- **`endpoint`**: The accessible URI of the endpoint.
+
+- **`class_method`**: The Java class that handles incoming requests to the endpoint, such as a controller class for web endpoints or an API handler for API endpoints.


Will this be required field or optional? What will we have in case of struts actions ?

admd · 2024-11-15T13:27:03Z

accepted/00000-rbac.md

+
+- **`http_method`**: The HTTP method (e.g., GET, POST, PUT, DELETE) accepted by the endpoint. If multiple methods are supported, each should be defined as a separate endpoint since they typically serve different purposes.
+
+- **`auth_required`**: Indicates if the endpoint requires authorization.


If endpoint, will we have a separate namespace for such endpoints? What endpoints would usually fall in this category?

admd · 2024-11-15T13:32:36Z

accepted/00000-rbac.md

+
+### Namespace
+
+A **namespace** is a logical grouping of endpoints that performs a specific task and defines the smallest unit of access control.


How will we make sure that we don't miss endpoints which are not part of any namespace? my question is more going forward - will we have any tooling which identify this?

admd · 2024-11-15T13:33:46Z

accepted/00000-rbac.md

+    - `clm.project.list`: Allows viewing the CLM projects list.
+    - `clm.project.details`: Allows viewing or modifying the details of a CLM project.
+
+- **`access_mode`**: Defines the access level for each namespace as either "View" (R) or "Modify" (W). Many namespaces will have separate entries for each mode, with different endpoints for each purpose.


I believe actions like export CSV will go under view(R) and delete under W, right?

admd · 2024-11-15T13:35:20Z

accepted/00000-rbac.md

+
+A **namespace** is a logical grouping of endpoints that performs a specific task and defines the smallest unit of access control.
+
+- **`namespace`**: A label representing the namespace, expressed as a dot-separated string of components. Each component corresponds to a level of hierarchy for a task, with related tasks sharing the same components at higher levels.


can an end point be part of more than 1 namespace?

admd · 2024-11-15T13:38:48Z

accepted/00000-rbac.md

+
+- **`scope`**: Indicates whether the endpoint is accessible through the web UI (including internal API calls) or the public API.
+
+#### Organization of namespaces


We don't have any table to represent this in our sample database schema, right? will we have some kind of inheritance here that if I have access at the top level namespace, I get access to everything else. And if yes, can as an admin, still change it to be more granular.

admd · 2024-11-15T13:43:38Z

accepted/00000-rbac.md

+- System Group Administrator
+- Read-only API User
+
+Each of these roles grants access to different features in Uyuni. This static access control is enforced individually within each feature. Stripping these control checks throughout the system requires significant effort. Therefore, in the initial phase, the logic of these static roles will coexist with their RBAC counterparts, but will be bypassed by assigning them to all existing and future users. This will effectively make RBAC the exclusive access control mechanism.


This is not clear to me. Yes, we will keep the existing roles so we don't break the users setup when the migrate to 5.1. But wow are we planning to get rid of them? Will we allow administrators to still play with old roles ? Having new and old permissions setup could be pretty confusing for the admin to understand.

admd · 2024-11-15T13:46:31Z

accepted/00000-rbac.md

+Users can be granted access either individually or through access groups.
+
+Users assigned to an access group inherit all permissions defined within that group.
+While administrators can grant individual users additional permissions beyond those provided by their assigned group, they cannot revoke permissions set by the group. Additionally, users can belong to multiple access groups and inherit all associated access rules.


hmm, I didn't get this. Here additional permissions means which are not covered by groups or is it more in a sense that those permissions that user got through groups can be overridden by individually assigning to the user?

admd · 2024-11-15T13:48:41Z

accepted/00000-rbac.md

+Users assigned to an access group inherit all permissions defined within that group.
+While administrators can grant individual users additional permissions beyond those provided by their assigned group, they cannot revoke permissions set by the group. Additionally, users can belong to multiple access groups and inherit all associated access rules.
+
+Predefined access groups are designed to meet the needs of most environments; however, administrators can create custom groups to address specific requirements as needed.


Does this mean that namespaces will be static and administrator cannot change them or create new ones or will we provide the same flexibility(not considering here if that's good or bad) there as well that we are providing here in case of access groups?

admd · 2024-11-15T13:52:30Z

accepted/00000-rbac.md

+- Prevent access to sensitive image store information:
+
+  ```
+  Revoke 'View' on 'cm.store.details' from 'Alice'


If Alice got this 'View' access through one accessgroup but then here Alice got that permissions revoked, I expect this would take precedence or?

RFC: Role-Based Access Control (RBAC)

a31de53

cbbayburt requested review from cbosdo, mcalmer, deneb-alpha, srbarrios, rjmateus, Etheryte, meaksh, jcayouette, admd, ktsamis, wweellddeerr, bisht-richa and parlt91 November 12, 2024 13:06

cbbayburt self-assigned this Nov 12, 2024

Etheryte reviewed Nov 12, 2024

View reviewed changes

accepted/00000-rbac.md Show resolved Hide resolved

Etheryte reviewed Nov 12, 2024

View reviewed changes

accepted/00000-rbac.md Show resolved Hide resolved

Etheryte reviewed Nov 12, 2024

View reviewed changes

aaannz reviewed Nov 12, 2024

View reviewed changes

rjmateus reviewed Nov 13, 2024

View reviewed changes

Clarify AAA framework terms

e34243b

cbbayburt added 2 commits November 13, 2024 18:49

Clarify plan on existing roles

17f7f92

Minor edits

09ab1e8

cbbayburt requested a review from szachovy November 13, 2024 17:55

Update ER diagram

6f850e2

Etheryte approved these changes Nov 13, 2024

View reviewed changes

cbbayburt requested a review from CDellaGiusta November 14, 2024 09:12

rjmateus approved these changes Nov 14, 2024

View reviewed changes

szachovy reviewed Nov 14, 2024

View reviewed changes

admd reviewed Nov 15, 2024

View reviewed changes


		## Overview

		This solution stores all available network endpoints in the database and determines which endpoints each user can access, with the exception of the Uyuni Administrator role, which bypasses access control.

	This solution stores all available network endpoints in the database and determines which endpoints each user can access, with the exception of the Uyuni Administrator role, which bypasses access control.
	This solution stores all available system endpoints in the database and determines which endpoints each user can access, except the Uyuni Administrator role, which bypasses access control.


		For example, `clm.project.details` [R] allows viewing a project's details, where `clm.project.details` [W] allows modifying them.

		- `description`: A clear description of what a namespace grants access to.


		#### Existing roles

		To ensure a smooth transition, existing roles will remain until all JSP/Struts pages are fully removed. The new access control mechanism includes default user access groups replicating the following roles:


		- Granularity of access control: Should the RBAC model include finer-grained permissions, such as access by specific actions (create, update, delete) within a namespace, or is the proposed "View" vs. "Modify" access mode sufficient for most cases?

		- External integration needs: Will the RBAC system require compatibility with external authentication or access control systems, such as LDAP, and if so, what integration points are required to support this?


		- External integration needs: Will the RBAC system require compatibility with external authentication or access control systems, such as LDAP, and if so, what integration points are required to support this?

		- Additional access groups: Should predefined access groups be expanded to cover specific use cases beyond those mirroring existing roles?


		- `endpoint`: The accessible URI of the endpoint.

		- `class_method`: The Java class that handles incoming requests to the endpoint, such as a controller class for web endpoints or an API handler for API endpoints.


		- `http_method`: The HTTP method (e.g., GET, POST, PUT, DELETE) accepted by the endpoint. If multiple methods are supported, each should be defined as a separate endpoint since they typically serve different purposes.

		- `auth_required`: Indicates if the endpoint requires authorization.


		### Namespace

		A namespace is a logical grouping of endpoints that performs a specific task and defines the smallest unit of access control.


		A namespace is a logical grouping of endpoints that performs a specific task and defines the smallest unit of access control.

		- `namespace`: A label representing the namespace, expressed as a dot-separated string of components. Each component corresponds to a level of hierarchy for a task, with related tasks sharing the same components at higher levels.


		- `scope`: Indicates whether the endpoint is accessible through the web UI (including internal API calls) or the public API.

		#### Organization of namespaces

Role-Based Access Control (RBAC) #95

Are you sure you want to change the base?

Role-Based Access Control (RBAC) #95

Conversation

cbbayburt commented Nov 12, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cbbayburt Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

Etheryte commented Nov 12, 2024

rjmateus commented Nov 12, 2024

aaannz left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rjmateus Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cbbayburt commented Nov 13, 2024 • edited Loading

rjmateus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rjmateus Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cbbayburt Nov 13, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Etheryte commented Nov 13, 2024

thesp0nge commented Nov 13, 2024 • edited Loading

cbbayburt commented Nov 13, 2024

Etheryte left a comment

Choose a reason for hiding this comment

cbbayburt commented Nov 13, 2024

rjmateus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

admd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cbbayburt Nov 13, 2024 •

edited

Loading

rjmateus Nov 13, 2024 •

edited

Loading

cbbayburt commented Nov 13, 2024 •

edited

Loading

rjmateus Nov 13, 2024 •

edited

Loading

cbbayburt Nov 13, 2024 •

edited

Loading

thesp0nge commented Nov 13, 2024 •

edited

Loading