[BUG] No error message displayed if user with home IDP is locked

[guilhem-lk]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

If a user associated with a home IDP is locked in Keycloak, the home-idp-discovery authenticator prevents the user from being redirected to the IDP:

keycloak-home-idp-discovery/src/main/java/de/sventorben/keycloak/authentication/hidpd/discovery/email/DomainExtractor.java

Lines 18 to 29 in 6a39af3

	Optional<Domain> extractFrom(UserModel user) {
	if (!user.isEnabled()) {
	LOG.warnf("User '%s' not enabled", user.getId());
	return Optional.empty();
	}
	String userAttribute = user.getFirstAttribute(config.userAttribute());
	if (userAttribute == null) {
	LOG.warnf("Could not find user attribute '%s' for user '%s'", config.userAttribute(), user.getId());
	return Optional.empty();
	}
	return extractFrom(userAttribute);
	}

As a consequence, the username/password form is displayed without an error message. If the user does not have a password configured in Keycloak (which is our use case), he is stuck on this page without any indication of what to do next.

Expected Behavior

The authenticator should redirect the user to the home IDP, even if locked.

After IDP redirects the user back to Keycloak, the username/password form is displayed with the error message indicating that the user is locked.

This is the behavior when IDP is selected manually on login page.

Steps To Reproduce

No response

Version

- Keycloak: 22.0.5
- This extension: 23.0.0

Anything else?

No response

[sventorben]

Hey @guilhem-lk,

thanks for reporting this.

To better understand why the password form is shown in this case, could you provide more information on how your authentication flow is configured? Specifically, are there other authenticators or custom flows that might influence this behavior?

Regarding your expected behavior, it’s important to note that the scenario differs when the IDP is selected manually. When the IDP is selected manually, the user is not known to Keycloak. However, when entering an email address, Keycloak can look up the user through the home-idp-discovery extension. This is why I believe changing the behavior might not be appropriate in this context.

Does your setup have use cases where a local user might have a password configured in Keycloak? Understanding this will help us determine if the current behavior has broader implications.

Best,
Sven-Torben

[guilhem-lk]

Hello @sventorben,

We use a copy of the default browser flow, with the Home IdP Discovery authenticator inserted just before the sub-flow browser idp discovery forms:

When user is locked, the Home IdP Discovery alternative step does not trigger the redirection to the IDP and the Username Password Form is displayed.

Our use case is to enable authentication federation for a subset of our users by using this extension. For those users, we want that they rely exclusively on the IDP for authentication, thus they won't have a password configured in Keycloak.

That's why, when user is locked, he reaches a dead end when login/password form is displayed.

For the expected behavior, I made a mistake in the ticket description. After the IDP redirects the user back to Keycloak, I expect that the user validation will fail because the user is locked and that it will display this error page: