-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disable password change with SSO #12386
Comments
GitMate.io thinks possibly related issues are #10572 (Fix security settings if password change is disabled), #7378 ([personal settings] Move "Change password" to "Security"-settings ), #9474 (It'll be nice to have "disable password confirm" option), #8356 (Unable to change forgotten password), and #4115 (With SSO enabled you cannot enable apps due to second password prompt). |
Could you report this to the user_saml repo? |
I don't think this is specific to user_saml. There should be general options in the server to disable the user profile settings if they are handled by an external application. |
As far as I know most of the user backends do this on their own (either automatically or by preference), so if user_saml repo doesn't do it, report it there. It doesn't make sense to implement this in server, as there is no use in disabling it for local Nextcloud users IMHO. |
Ref #12671 we discussed the password case for https://github.com/nextcloud/user_saml/blob/a8f7d16c6a418bf8fce9a9b9ca3b0cef5b6747e0/lib/UserBackend.php#L173-L178 looks right to me. Please dont mix bug report and feature request.
Bug Report
Feature Request |
When using SSO with user_saml the password change form in the users security settings should not be visible, as the authentication is done via SAML only and no passwords are used within NC.
Also as the user_saml app might be extended to map more user attributes from the IdP to NC, it would be good to have the possibility of disabling the editing of the user attributes such as phone number, etc. For the users display name, this is already possible via
'allow_user_to_change_display_name' => false
, but not for other attributes.The text was updated successfully, but these errors were encountered: