Migrattion Wildfly 8 to Wildfly 28 - Problem with Login (@CustomFormAuthenticationMechanismDefinition)

Question

I am currently migrating an older application from WildFly 8 to WildFly 28. While I've resolved numerous issues, I have a problem with the login functionality. The application fails to log in under normal circumstances, and I've had to resort to a temporary workaround.

The application utilizes a custom IdentityStore which leverages our own database to authenticate users and verify passwords. This is implemented using the @CustomFormAuthenticationMechanismDefinition annotation. The specific implementation details are as follows:

@CustomFormAuthenticationMechanismDefinition(
        loginToContinue = @LoginToContinue(
                loginPage = "/pages/login.xhtml",
                errorPage = "", // DRAFT API - must be set to empty for now
                useForwardToLogin = false
        )
)
@ApplicationScoped
@DeclareRoles({....})
public class InputIdentityStore implements IdentityStore {

    @Inject
    protected SessionManager sessionController;

    protected UserService userService;

    @PostConstruct
    public void init() {
        this.userService = ServicesUtil.getUserService();
    }

    public CredentialValidationResult validate(UsernamePasswordCredential usernamePasswordCredential) {
        UserResult user = this.userService.authenticate(usernamePasswordCredential.getCaller(), usernamePasswordCredential.getPasswordAsString());

        if (user != null) {
            HashSet<String> userRoleHashSet = new HashSet<>();
            for (RoleResult roleResult : user.getRoleList()) {
                userRoleHashSet.add(roleResult.getName());
            }
            userRoleHashSet.add("authenticated");

            JacqCallerPrincipal jacqCallerPrincipal = new JacqCallerPrincipal(user.getUsername(), user, usernamePasswordCredential.getPasswordAsString());

            // remember authorization header in session controller
            sessionController.setAuthorizationHeader("Basic " + Base64.encodeBase64String((usernamePasswordCredential.getCaller() + ":" + usernamePasswordCredential.getPasswordAsString()).getBytes()));
            // remember user object in session controller
            sessionController.setUser(jacqCallerPrincipal.getUser());

            return new CredentialValidationResult(jacqCallerPrincipal, userRoleHashSet);
        }

        return CredentialValidationResult.INVALID_RESULT;
    }

}

I've taken the precaution of masking the DeclaredRoles in this explanation to protect sensitive internal information.

The implementation appears to be functioning correctly, as it returns a CredentialValidationResult complete with the principal and a HashSet of user roles. However, I've noticed that the getCallerGroups method is neither overridden nor called in our process. This might be due to the CredentialValidationResult already containing the role information.

Through debugging and analysis, I discovered that the application is also referencing the application-users.properties file for user authentication. This file is part of the ApplicationRealm. Interestingly, adding the user to this file seems to resolve the login issue, which I am currently using as a workaround to proceed with the migration.

However, I am seeking a more permanent solution. I'm puzzled as to why application-users.properties is being utilized for authentication and what configurations are necessary to ensure that the IdentityStore alone suffices for login processes. Could there be a misunderstanding on my part regarding this functionality? I would appreciate any insights or suggestions on how to address this issue.

Thanks in advance.