Role-Based Access Control (RBAC)

[cbbayburt]

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

See the rendered version.

[Etheryte]

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?

[rjmateus]

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.

[cbbayburt]

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]

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]

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]

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.

[rjmateus]

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

[cbbayburt]

I'll try to rephrase this to be more clear

[cbbayburt]

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.

[aaannz]

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.

[aaannz]

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.

[rjmateus]

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.

[rjmateus]

@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?

[cbbayburt]

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

[aaannz]

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.

[cbbayburt]

Noted. Thanks for the tip.

[cbbayburt]

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]

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]

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.

[cbbayburt]

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]

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]

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

[rjmateus]

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.

[cbbayburt]

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?

[rjmateus]

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.

[cbbayburt]

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]

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

[cbbayburt]

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.

[rjmateus]

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]

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]

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]

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]

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

[cbbayburt]

@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]

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]

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]

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

[rjmateus]

This is mandatory, especially for the XML-RPC API endpoint, where we use this field to control access. For Structs and spark-only endpoints this is not really needed, but we can populate it.

[admd]

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

[rjmateus]

simples example, login page. You don't need to be authenticated to reach it, otherwise user cannot login.

[admd]

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?

[rjmateus]

We can develop a tool. But the side effect will be super visible, because users will not be able to access the base and feature will not work.

[cbbayburt]

So when you're implementing a new URL for a feature, first thing you'll have to do is to add necessary entries (endpoint and namespace info) to the RBAC tables using schema migration. Otherwise you won't be able to visit the URL when testing yourself.

[srbarrios]

I support the idea of Abid to have some kind of tool part of the unit tests that assure that we don't miss any. Let's not rely only to the side effect even if easy to see. But let's be sure that someone adding a new endpoint in a new Pull Request have feedback if that part is missing.

[admd]

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

[rjmateus]

I think that is the goal, but Can can give more insides if needed.

[cbbayburt]

Correct. AFAICS this separation is clear enough for any action. Management UI will provide proper descriptions for each namespace and mode so it'll be clear to users.

Ideally, the UI should have free text search so for example you'll be able to search for the keyword CSV and see what namespaces are available for any CSV related action.

[admd]

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

[rjmateus]

yes

[cbbayburt]

We have many cases already. Mostly with some reusable URLs like getting a JSON system list etc. This also aligns with the fact that we want to unify API endpoints to be used by both the public API and the frontend pages.

[srbarrios]

We'll be able to identify if an endpoint is called for one or other namespace?
I'm thinking about telemetry from the point of view of our features.

[rjmateus]

From telemetry is not possible o see, we can only see that and endpoint is called. What we can do is we log all the called, be able to calculate a call trace and deduct what could have be the interaction path.

[admd]

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.

[rjmateus]

If I got it right, the idea is to have this in an indirect way, by playing with the label name. For example:
namespace: admin
namespace: admin.createUser

[cbbayburt]

If I got it right, the idea is to have this in an indirect way, by playing with the label name.

Correct. By default, granting access to a parent namespace doesn't automatically give access to the children. For that, you'll need to explicitly say "grant access to this namespace and everything that falls below it".

[admd]

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.

[rjmateus]

There are 2 roles that needs to stay for now, which are satadmin and orgadmin.
Other roles should be replaced with new user groups in the new system.
Internally, we may need to keep the old roles because of struts ACL configurations.

[cbbayburt]

Even though the older logic stays for now, it won't be visible to any user or admin.

[admd]

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?

[rjmateus]

The idea is to grant more permissions to the user. User will always have access to all endpoints granted in all the groups, plus all individual permissions grant to the user directly.

[admd]

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?

[rjmateus]

Namespaces and access groups are just different levels of putting endpoints together. Namespaces are static and controled by us. Users can then create user groups linked to the endpoint in any shape or form, that will put together one or more namespaces.
On top of that, we will also have a few user groups controlled by us and the goal is that those groups match the existing roles.

[admd]

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

[cbbayburt]

As mentioned here:

While administrators can grant individual users additional permissions beyond those provided by their assigned group, they cannot revoke permissions set by the group.

Permissions assigned through a group cannot be revoked individually. This is an arbitrary limitation I wanted to enforce because otherwise it could get really messy for admins after a while. If we see the need for this, we can change the logic to allow this.

So for the example above, you cannot simply make Alice an Image Admin. If you do, you cannot revoke access to cm.store.details because it's part of the Image Admin role.

[rjmateus]

If it's removed from User direct grant but is still present in the group, then Alice still has access to the feature. All endpoints are revoked by default, and we are always adding/grant access in all levels we can configure.

[ktsamis]

So from what I understand with the new UI pages or API endpoints we would be using/testing it somehow like this, right? I put a few user stories with an example feature just to get an idea if I understand it correctly

User Story 1: Admin assigns access groups to users
As an administrator,
I want to assign a user to an access group,
So that they can access the features allowed by the group.

User Story 2: User accesses a feature within their namespace
As a user,
I want to access features and operations allowed by my role,
So that I can perform my job functions.

User Story 3: Unauthorized user attempts to access restricted resources
As a user,
I want the system to prevent me from accessing unauthorized features,
So that security and access rules are maintained.

User Story 4: Admin customizes access for a user
As an administrator,
I want to customize individual permissions for a user,
So that their access meets specific requirements.

User Story 5: Admin creates a new access group
As an administrator,
I want to create new access groups with specific permissions,
So that I can manage user access more efficiently.

User Story 6: User loses access when removed from a group
As an administrator,
I want users to lose permissions immediately when removed from an access group,
So that their access remains strictly controlled.

User Story 7: Permissions propagate correctly for multi-group users
As a user,
I want permissions from multiple groups to apply seamlessly,
So that my access covers all assigned roles.

Feature: Multi-group user access

Scenario: User belongs to multiple access groups with overlapping permissions
  Given a user "testuser" belongs to the access groups:
    | Group Name        | Namespace             | Access Mode |
    | Image Viewer      | cm.image.list         | View        |
    | Profile Manager   | cm.profile.*          | Modify      |
  When "testuser" logs in
  Then "testuser" should have the following combined permissions:
    | Namespace             | Access Mode |
    | cm.image.list         | View        |
    | cm.profile.*          | Modify      |
  And "testuser" should be able to modify image profiles
  And "testuser" should not be able to delete images

User Story 8: Audit access logs
As an administrator,
I want to track and log user actions,
So that I can audit access and detect misuse.