For some, you might want to enforce access managed on the manage scope. I think we should try first the check with reset-password scope and if it fails, we then check manage.

There is a performance penalty with this approach, but perhaps it covers more use cases and avoid forcing people to always set reset-password if the manage scope is enough.

@vramik Can you also give your thoughts on this one?

This is my first time working with this part of Keycloak, so I initially approached the implementation with the goal of making password reset permissions more granular and policy-driven. I wanted RESET_PASSWORD to be a distinct capability, so that realm admins with MANAGE_USERS wouldn't automatically get this right unless allowed explicitly via a policy.
That said, I totally understand that falling back to MANAGE_USERS when no RESET_PASSWORD policies are defined makes the behavior more compatible by default.
If this approach is preferred, I’d really appreciate if someone from the team could help adjust the fallback logic in the PR. But I’m also happy to update it myself if needed.

I will take a look and contribute the fallback. Let's see first what @vramik has to say about it.

Hi @pedroigor and @Bagautdino, thanks for the discussion on this.

I've been thinking about the implicit fallback from RESET_PASSWORD to MANAGE_USERS. While I understand the goal of backward compatibility, I'm a bit concerned that an implicit fallback could be error-prone and harder to maintain in the long run. It couples two distinct permissions, which might lead to confusion for administrators who expect RESET_PASSWORD to be the single source of truth for this capability.

I believe we should follow opt-in approach when dealing with fallbackToManageUsers. As far as I am aware this is also preferred way how to introduce behavioral changes. What are your thoughts on it?

This leads me to a broader question for @pedroigor: what are the team's general policies around changing default settings? With an explicit option in place, perhaps we could plan to switch the default to a more secure setting (i.e., fallback disabled) in a future major release?

Hi @vramik, thanks a lot for the detailed feedback 🙏

I’ve updated the implementation to follow the opt-in fallback approach:
If there are any RESET_PASSWORD policies, they are the single source of truth (deny-overrides, secure-by-default).
Only when no policies exist, and the flag fgap.v2.resetPassword.fallbackToManageUsers=true is set, we fallback to MANAGE_USERS.
With no policies and the flag disabled (default), reset password is denied.

Thanks a lot, I probably didn't express myself good enough. Sorry about that. What I mean by opt-in approach is something like this

    @Override
    public boolean canResetPassword(UserModel user) {
		// admin roles has the precedence over permissions
		if (root.hasOneAdminRole(AdminRoles.MANAGE_USERS)) {
            return true;
        }

		// by default use legacy behavior - with the aim to change the default in next major release
		boolean fallbackToManage = Config.scope("fgap", "v2", "resetPassword").getBoolean("fallbackToManageUsers", true);

		if (fallbackToManage) {
			return eval.hasPermission(new UserModelRecord(user), null, AdminPermissionsSchema.MANAGE);
		}

		return eval.hasPermission(new UserModelRecord(user), null, AdminPermissionsSchema.RESET_PASSWORD);
	}

So that user who would like to leverage the RESET_PASSWORD permission, would need to pass the fallbackToManageUsers=false option. In next version we might be able to switch the default to false, it should provide users some time to leverage new behavior. WDYT?

Got it, thanks for clarifying 🙏 I’ve updated the implementation to follow this opt-in fallback approach with fallbackToManageUsers=true as the current default. Let me know if you’d like any further adjustments 👍

Sorry for the late reply. I'm not sure about introducing the fallbackToManageUsers. For me, we can just check if the reset password scope is set, and if not we check the manager scope.

Or is there any backward compatibility issue with this approach?

The variable is not used, can we remove it?

removed

isAdminPermissionsEnabled(root.realm) also tests for the realm being null and returns false in that case, it seems that the second part of the if is redundant. wdyt?

I’ve removed the redundant root.realmResourceServer() == null check and simplified the condition as suggested. Thanks!

Hi @pedroigor and @Bagautdino, thanks for the discussion on this.

I've been thinking about the implicit fallback from RESET_PASSWORD to MANAGE_USERS. While I understand the goal of backward compatibility, I'm a bit concerned that an implicit fallback could be error-prone and harder to maintain in the long run. It couples two distinct permissions, which might lead to confusion for administrators who expect RESET_PASSWORD to be the single source of truth for this capability.

I believe we should follow opt-in approach when dealing with fallbackToManageUsers. As far as I am aware this is also preferred way how to introduce behavioral changes. What are your thoughts on it?

This leads me to a broader question for @pedroigor: what are the team's general policies around changing default settings? With an explicit option in place, perhaps we could plan to switch the default to a more secure setting (i.e., fallback disabled) in a future major release?