[Regression 3.3.3] OrmResolver config (userModel/finder) is ignored when nested under 'resolver' in PasswordIdentifier

[gfx3]

I'm reporting a regression found in the cakephp/authentication plugin, specifically version 3.3.3. Version 3.3.2 works as expected.

The configuration for the OrmResolver is correctly passed to AuthenticationService::loadIdentifier(), but the nested keys ('userModel', 'finder') are stripped or lost when the PasswordIdentifier is initialized, causing the OrmResolver to fall back to its default model, 'Users', instead of the intended one, e.g., 'Members'.

This prevents any non-default user model from being authenticated.

The following configuration, designed to use the 'Members' model:

$service->loadIdentifier('Authentication.Password', [
    'resolver' => [
        'className' => 'Authentication.Orm',
        'userModel' => 'Members', // This configuration is lost in 3.3.3
        'finder' => 'all',
    ],
    'fields' => ['username' => 'email', 'password' => 'password'],
]);

Output from AuthenticationService::loadIdentifier() (Configuration is correct):

'Authentication.Password'
[
    'resolver' => [
        'className' => 'Authentication.Orm',
        'userModel' => 'Members', // Correctly present here
        'finder' => 'all',
    ],
    // ...
]

Output from OrmResolver::__construct() (Configuration is lost):

// Contents of $config array received by OrmResolver::__construct()
[
    'className' => 'Authentication.Orm', // Only this key remains
]

CakePHP version: 5.2.9
Authentication version: 3.3.3 (not working)
Authentication version: 3.3.2 (working)

[dereuromark]

I cannot reproduce this issue. All configuration scenarios work correctly - userModel and finder are properly passed to the OrmResolver.

Here's a summary of what I tested:

Scenario	Result
loadIdentifier() with nested resolver config	✅ Works
identifier config in authenticator	✅ Works
Constructor config with identifiers array	✅ Works
Mixed old/new style (loadIdentifier + loadAuthenticator)	✅ Works
Direct PasswordIdentifier construction	✅ Works

The resolver config flows correctly through:

1. AuthenticationService → IdentifierCollection → PasswordIdentifier → ResolverAwareTrait::buildResolver() → OrmResolver

Can you provide:

1. A minimal reproducible test case
2. Complete authentication configuration code
3. Any custom middleware or overrides you might have

[dereuromark]

Note that loadIdentifier() usage is deprecated. Directly pass Identifier to Authenticator.
But that should not break BC of course.

[dereuromark]

I think I found it:

The bug occurs when loadIdentifier() is called AFTER loadAuthenticator():

1. loadAuthenticator('Authentication.Form') triggers authenticators() → identifiers()
2. At this point, _identifiers is null, so an empty IdentifierCollection is created
3. FormAuthenticator.__construct() sees the empty collection and creates its own default PasswordIdentifier (with default resolver config)
4. Later, loadIdentifier() adds to the service's collection, but the authenticator already has a separate collection

[gfx3]

That's the case:

The bug occurs when loadIdentifier() is called AFTER loadAuthenticator()

I updated plugin to version 3.3.3 and moved loading identifier before loading authenticators and userModel is passed correctly.