Project

General

Profile

Actions

Bug #23254

closed

User management plugin incorrectly understands OIDC roles

Added by Roni Väyrynen over 1 year ago. Updated 11 months ago.

Status:
Released
Priority:
N/A
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
0
Name check:
To do
Fix check:
Checked
Regression:
No

Description

I have OIDC configured (utilizing Okta) successfully and user logins are working fine, even custom groups are fetched from a specific attribute. What doesn't work is the roles override option, which should reset the users roles to whatever is provided by the OIDC that match an existing custom role. Below is an example how i have this setup:

in rudder-users.xml:

<authentication case-sensitivity="true" hash="bcrypt">
    <custom-roles>
        <role permissions="read_only" name="Team - ReadOnly"/>
        <role permissions="administrator" name="Team - Administrator"/>
    </custom-roles>
    <user name="firstname.lastname@company.tld" permissions="Team - ReadOnly,Team - Administrator"/>

Based on documentation, what i'm expecting to happen. OIDC auth method reads the groups from an attribute, matches them to existing custom roles and then either appends or overrides the configured roles in the user block. Even the log suggests that this would happen:

[2023-08-10 11:28:23+0000] DEBUG auth-backends - Identifying OIDC user info with sub: 'xxx' on rudder user base using login: 'firstname.lastname@company.tld'
[2023-08-10 11:28:23+0000] INFO  application.authorization - Principal 'firstname.lastname@company.tld' role list extended with OIDC provided roles: [Team - ReadOnly] (override: true)
[2023-08-10 11:28:23+0000] DEBUG auth-backends - Principal 'firstname.lastname@company.tld' final list of roles: [Team - ReadOnly]

Although in the UI the user still has full administrator permissions which comes from the Team - Administrator role. This can also be observed from the User Management UI section, where user has an administrator role.

At first i tested this with a custom role and one of the pre-defined default roles in the user block and thought the plugin would target only custom roles, but seems that the behaviour is same with both, roles aren't actually overwritten as they should.

I've tested this with following:

rudder-plugin-auth-backends latest release version 7.3.4-2.6 and with 7.3.5-2.6-nightly
rudder-plugin-user-management latest release version 7.3.4-2.2 and with 7.3.5-2.2-nightly


Files


Related issues 6 (3 open3 closed)

Related to Authentication backends - Bug #23306: OIDC authentication backend is not listed in user-management pluginNewFrançois ARMANDActions
Related to Rudder - Bug #23098: Plugin cannot add custom roles or it will be overwritten by boot custom roles ReleasedVincent MEMBRÉActions
Related to Rudder plugins - Bug #23348: not allowed to access errors because rudder plugins are missing AuthorizationApiMapping ReleasedVincent MEMBRÉActions
Related to Rudder - Bug #23313: Extend authentication methods to know about roles overrideNewFrançois ARMANDActions
Related to Authentication backends - Bug #23314: Update role overriding warning based on actual OIDC configurationNewFrançois ARMANDActions
Related to Rudder - Bug #24230: Authentication providers and role mapping settings should be exposedReleasedVincent MEMBRÉActions
Actions #1

Updated by François ARMAND over 1 year ago

  • Target version set to 7.3

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

Actions #2

Updated by Roni Väyrynen over 1 year ago

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.

Actions #3

Updated by François ARMAND over 1 year ago

  • Subject changed from OIDC roles override is not working to User management plugin incorrectly understand OIDC roles

OK, so the problem is indeed likely in user management plugin.

I'm updating the title accordingly.

So there's at least 3 aspects :

- problem with user management plugin reporting / managing oidc provided permissions
- user management access with overrided permission (or more broadly?)
- errors in ui when base role list is empty

Actions #4

Updated by Roni Väyrynen over 1 year ago

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.

Actions #5

Updated by François ARMAND over 1 year ago

I'm working on that topic and try to reproduce, taking notes along the side.
Version: Rudder 7.3.6-SNAPSHOT ; auth-backend 7.3.6-2.6-nightly ; user-management 7.3.6-2.2-nightly
For now:

OIDC user with xml file role: [administrator] ; OIDC provided role with override: [read_only]

In XML: <role name="role-oidc-a" permissions="read_only" />
User role in log: ... role list extended with OIDC provided roles: [role-oidc-a] (override: true)

User can log in and seems to have correct access BUT for plugins where I get: Authorization error: User 'xxx' is not allowed to access GET secure/api/usermanagement/users , for ex:

=> seems to be linked to: https://issues.rudder.io/issues/23098 where plugins don't "add" their right to base roles

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?

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 ?

Actions #6

Updated by François ARMAND over 1 year ago

  • Related to Bug #23306: OIDC authentication backend is not listed in user-management plugin added
Actions #7

Updated by François ARMAND over 1 year ago

  • Related to Bug #23098: Plugin cannot add custom roles or it will be overwritten by boot custom roles added
Actions #8

Updated by François ARMAND over 1 year ago

  • Status changed from New to In progress
  • Assignee set to François ARMAND
Actions #9

Updated by François ARMAND over 1 year ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from François ARMAND to Vincent MEMBRÉ
  • Pull Request set to https://github.com/Normation/rudder-plugins/pull/592
Actions #10

Updated by Roni Väyrynen over 1 year ago

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
Actions #11

Updated by François ARMAND over 1 year ago

  • Subtask #23313 added
Actions #12

Updated by François ARMAND over 1 year ago

  • Subtask #23314 added
Actions #13

Updated by François ARMAND over 1 year ago

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.

Actions #14

Updated by Anonymous over 1 year ago

  • Status changed from Pending technical review to Pending release
Actions #15

Updated by François ARMAND over 1 year ago

  • Related to Bug #23348: not allowed to access errors because rudder plugins are missing AuthorizationApiMapping added
Actions #16

Updated by Vincent MEMBRÉ over 1 year ago

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

Actions #17

Updated by Alexis Mousset about 1 year ago

  • Subject changed from User management plugin incorrectly understand OIDC roles to User management plugin incorrectly understands OIDC roles
Actions #18

Updated by François ARMAND about 1 year ago

Warning message present and correct list of providers

Actions #19

Updated by Vincent MEMBRÉ about 1 year ago

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

Actions #20

Updated by François ARMAND 11 months ago

  • Subtask deleted (#23313)
Actions #21

Updated by François ARMAND 11 months ago

  • Related to Bug #23313: Extend authentication methods to know about roles override added
Actions #22

Updated by François ARMAND 11 months ago

  • Subtask deleted (#23314)
Actions #23

Updated by François ARMAND 11 months ago

  • Related to Bug #23314: Update role overriding warning based on actual OIDC configuration added
Actions #24

Updated by François ARMAND 11 months ago

  • Status changed from Pending release to Released
Actions #25

Updated by Clark ANDRIANASOLO 10 months ago

  • Related to Bug #24230: Authentication providers and role mapping settings should be exposed added
Actions

Also available in: Atom PDF