[Feature] Block user edit values given by OpenID

[Zocker1999NET]

After I got a running Keycloak and Nextcloud connection, I saw that the login attributes where also mapped correctly, which is really great, but nextcloud still allows the user to edit these values. Also this app does not allow disabling changing password or two-factor authentication for the user. Changes to attributes like name or mail (if given by Keycloak) will be discard on the next login, which could potentially confuse users.

I want to remove these abilities from Nextcloud because the user should manage their credentials and information only on Keycloak.

[pulsejet]

Hi! You can disable allowing changing the user's name by adding this to the config

'allow_user_to_change_display_name' => false,

Nextcloud doesn't provide any way to disable changing other attributes in my knowledge, and that would pretty much be out of scope for this plugin. Keeping this open nonetheless in case anyone has any suggestions.

[yrammos]

As a temporary kludge, couldn't one just hide UI controls in question with { display: none; } CSS lines? I think there's at least one NextCloud plugin allowing CSS injections.

[pulsejet]

@yrammos I can't recommend that unless the administrator is doing it at their own risk. If a plugin hides an input, it is easy to assume that the changes will be server side validated - anything otherwise would classify as a security risk.

[yrammos]

@pulsejet I agree with you, hence "temporary kludge"…

As far as I know, the LDAP plugin does what @Zocker1999NET is asking about — maybe worth taking a look in that direction? Using OpenID without a centralized repository of account info seems to me inherently problematic.

[michel-zimmer]

Hi, I'm wondering how to disable the password change from under the security settings for users. I've followed various issues and it seems as if this is the correct way:
nextcloud/server#12671 (comment)
There it has been cited, that the form is displayed depending on if the user object exposes a password change capability. Apparently this depends on the backend. I don't know how Nextcloud is modelled, but as far as I can tell, this OIDC App does not implement a custom backend. This would mean that this App currently cannot hide the password change form using the methods provided by Nextcloud. Is that correct?
Do you have a suggestion how to hide the password change form, @pulsejet ?

[pulsejet]

Yep, we use either the default user backend or the LDAP backend depending on configuration. I have no idea how we could tell the backend to disallow password change.

Also note a user may want to be able to login with the password as well as OIDC, maybe unless the user was created with OIDC. Don't think we can handle that case anyway.

[michel-zimmer]

Okay, thanks for confirming. In my case users are handled entirely by OIDC and the users should not deal with credentials inside Nextcloud. I think I'm going to hide the password login and the password change forms via CSS until a cleaner solution comes up. They don't work anyway and just create confusion.

[pulsejet]

Please do comment what exact solution you use for others' benefit.

[tekhnee]

Well, one rudimentary but workable solution would be to inject the following via the "Custom CSS" textbox, under "Administration > Theming."

#security-password {
    display: none;
}

#two-factor-auth  {
    display: none;
}

#security-webauthn {
    display: none;
}

I don't see any substantial security implications but would welcome any thoughts on how this hack could pose an actual threat, even if a malicious user discovered it.

[pulsejet]

Hmm, maybe I didn't check properly which attributes the OP was referring to, but if you're hiding only the user's private security parameters here then it indeed should not be an issue. In that case I'd accept a PR to add this functionality to the plugin (with a clear warning that we don't do server side validation, just so that administrators don't rely in any way on the user passwords).

[tekhnee]

PR submitted as #59.

This should implement the core feature. Would you be able to pick it up from there, @pulsejet? I don't quite understand what the content or location of the "warning" should be.

[pulsejet]

PR submitted as #59.

This should implement the core feature.

Awesome!

Would you be able to pick it up from there, @pulsejet?

I don't have a test environment, so that'll take time. I'll get to it though.

I don't quite understand what the content or location of the "warning" should be.

Documentation. Basically this needs to be configurable (and default to being turned off), and the config option in the README must have this warning.

[tekhnee]

New PR submitted as #60 (closed #59 due to a git history rewrite on my end).

[pulsejet]

Fixed by #60