[Improvement-18383][API] Disable create user, reset password, and username edit in non-PASSWORD auth modes

[njnu-seafish]

Was this PR generated or assisted by AI?

YES. Use AI to find and modify the code, then test and verify it locally.

Purpose of the pull request

close #18383

Brief change log

Disable create user, reset password, and username edit in non-PASSWORD auth modes

Verify this pull request

This pull request is code cleanup without any test coverage.

(or)

This pull request is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(or)

Pull Request Notice

Pull Request Notice

If your pull request contains incompatible change, you should also add it to docs/docs/en/guide/upgrade/incompatible.md

[njnu-seafish]

Do we also need to add a check for the PASSWORD authentication type in the backend controllers? If the authentication mode is non-PASSWORD, the backend should not allow operations such as user creation and password modification.

[SbloodyS]

Do we also need to add a check for the PASSWORD authentication type in the backend controllers? If the authentication mode is non-PASSWORD, the backend should not allow operations such as user creation and password modification.

Yes. Both front-end and back-end need to be modified, please submit it in this PR.

[SbloodyS]

The frontend checks added in this PR rely on userStore.getSecurityConfigType, but the OAuth2/OIDC redirect path only stores the session and userInfo. Because the user store is persisted, a browser that previously logged in with PASSWORD can keep a stale securityConfigType === 'PASSWORD', so OIDC/OAuth2 users may still see enabled create/reset/password UI. The redirect login path should also populate the current security config type before entering the app.

[SbloodyS]

This rejects unchanged usernames too. Normal non-credential edits such as email/phone/tenant/state now fail in LDAP/OIDC/SSO mode.

[njnu-seafish]

This rejects unchanged usernames too. Normal non-credential edits such as email/phone/tenant/state now fail in LDAP/OIDC/SSO mode.

Very thorough.

[njnu-seafish]

The frontend checks added in this PR rely on userStore.getSecurityConfigType, but the OAuth2/OIDC redirect path only stores the session and userInfo. Because the user store is persisted, a browser that previously logged in with PASSWORD can keep a stale securityConfigType === 'PASSWORD', so OIDC/OAuth2 users may still see enabled create/reset/password UI. The redirect login path should also populate the current security config type before entering the app.

The level of thoroughness in this review is outstanding. Really impressive work! Your review is very thorough.

[SbloodyS]

The PR marks OAuth2 redirect logins as securityConfigType=OAUTH2 on the frontend, but the backend guard in UsersServiceImpl checks only security.authentication.type. OAuth2 is enabled separately and can be used together with PASSWORD, so in that common setup the UI disables create/reset/edit-password, but /users/create, /users/update, and /users/register still pass the backend guard because security.authentication.type remains PASSWORD.

[njnu-seafish]

The PR marks OAuth2 redirect logins as securityConfigType=OAUTH2 on the frontend, but the backend guard in UsersServiceImpl checks only security.authentication.type. OAuth2 is enabled separately and can be used together with PASSWORD, so in that common setup the UI disables create/reset/edit-password, but /users/create, /users/update, and /users/register still pass the backend guard because security.authentication.type remains PASSWORD.

ok, add logic to reject password-managed user operations when OAuth2 is enabled.