Rudder plugins » Authentication backends

François ARMAND wrote in #note-1:

Hello,

You correctly understood the semantic of override, and the logs seems to say that it should be as you intented.

Ça you confirm that the user is actually able to (for ex) modify a directive and save it?
(I would like to remove the possibility of UI bugs, with correct backend permission applied).

Can you also confirm that if the user has no base role, it correctly get the ones from okta (and not admin) ?

Good point, now that you asked it. It indeed seems like the user actually has read_only permissions elsewhere, but is still able to create/modify users in the user management page. One additional thing i noticed is a bit off, the user management shows "Default authentication method is used". Even if i disable the file authentication completely and leave only oidc enabled. If i enable ldap, it is being listed properly there besides file method (if enabled), so seems to be related to oidc specifically.

So based on this, it sounds more like an issue in the user management plugin which is showing/using wrong permissions?

By "no base role" you mean if i leave the permissions section out completely in rudder-users.xml for that specific user (which is how i'd love this to work actually)? If i do that, the auth-backends plugin still logs the same during login but user experience is completely different. I can see the UI but i'm getting random errors from pretty much every page with different "Authorization error... is not allowed to access" log entries. If i login with the default admin and go to the user management section, the oidc user has no roles listed.

Just to note, this is a fresh installation of Rudder on a fresh Debian 12 OS with just the necessary rudder plugins and oidc config applied.

Yeah this sounds about right based on what i discovered so far. Let me know if you need me to test anything or gather additional logs.

François ARMAND wrote in #note-5:

I can confirm that:
- OIDC is missing from the list of provider priority
- OIDC roles are not correct when override is set to true.

For that last one, we are obviously not doing what is right: we are displaying the XML defined roles, which is false.
And of course, the goal of having OIDC provided roles that override the one in Rudder is to be able to manage from the idP user roles without Rudder knowing about the changes before login.

What we could do short term:
- add text to explain that the displayed roles are the one configured in the XML file
- when OIDC is selected and override is false, add a text saying that "that list of roles can be extended if OIDC login is used"
- when OIDC is selected and override is false, add a warning under the priority list saying "the role by OIDC will override these roles", and same kind of warning in the user role details

Longer term:
- add for each user the list of "last session" with the corresponding resolved right for that session. That would also allow to trace what rights a user used to have (in the more general case than OIDC auth) at some specific time and allows to do actual forensic/post mortem.

@Roni Väyrynen : what do you thing about that?

Sounds reasonable. Might want to also add some mentions about these to the documentation to avoid confusion.

When XML role is empty
Same behavior as above: incorrect list of roles in user management plugin, and perm errors for plugins.

QUESTION: @roni: can you confirm that the random 500 error "xxx is not allowed to access ..." are only for plugins (like user management, patch, cve, etc ?) but other parts (node info, rules, directives, etc) works well ? If not, can you give me example of auth error with the corresponding log so that I can try to reproduce ?

The UI errors come pretty much from every menu (including node info, rules etc) and are mostly different everywhere so difficult to give one distinct one. In logs i see errors only from different secure/api/xxx/xxx endpoints. One example below when trying to access nodes page:

[2023-08-18 10:58:59+0000] ERROR com.normation.rudder.rest.RestUtils - "Authorization error: User 'firstname.lastname@company.tld' is not allowed to access GET secure/api/user/api/token" 
[2023-08-18 10:58:59+0000] ERROR com.normation.rudder.rest.RestUtils - "Authorization error: User 'firstname.lastname@company.tld' is not allowed to access POST secure/api/nodes/details" 

UI gives an ajax error:

DataTables warning: table id=nodes - Ajax error. For more information about this error, please see http://datatables.net/tn/7

Sounds reasonable. Might want to also add some mentions about these to the documentation to avoid confusion.

Good point, done.

The UI errors come pretty much from every menu (including node info, rules etc) and are mostly different everywhere so difficult to give one distinct one. In logs i see errors only from different secure/api/xxx/xxx endpoints. One example below when trying to access nodes page:

[2023-08-18 10:58:59+0000] ERROR com.normation.rudder.rest.RestUtils - "Authorization error: User 'firstname.lastname@company.tld' is not allowed to access GET secure/api/user/api/token" 

This one is certainly an occurence of #23098: trying to access a plugin API on READ (should be allowed, but read_only rights not extended for loaded plugins)

[2023-08-18 10:58:59+0000] ERROR com.normation.rudder.rest.RestUtils - "Authorization error: User 'firstname.lastname@company.tld' is not allowed to access POST secure/api/nodes/details" 

This one is likely a legit bugs. We try to do a POST somewhere, so from a perm point of view, it was likely translated to "write needed". But that specific POST is maybe just for reading (IIRC, POST is needed b/c of complex parameter list/filtering). I need to check. If that, then we need to adapt permissions.
Else if its a legit write, it is OK to have it forbidden, and we need to remove access to the thing that triggered it.

This bug has been fixed in Rudder plugin user-management v8.0.0.beta1-2.2

This bug has been fixed in Rudder plugin user-management v7.3.6-2.2