This is just a first stab, but I have a script that can do this now - @weierophinney does this look right to you? I haven't tried rendering with Bookdown yet.

Attempted composer require zendframework/zend-authentication on the latest zf3 framework. Produced the following error:

[InvalidArgumentException]
Could not find package require at any version for your minimum-stability (d
ev). Check the package spelling or your minimum-stability

• No bugfix
• No new feature
• Fixing documentation

Typo []Account Name Canonicalization] was corrected to [Account Name Canonicalization] so it is a valid markdown link.

This allows the client code to supply his own domain-specific error codes. In my case these were expired account, disabled account, and password not set up.

It is also necessary for the client to supplement $this->messageTemplates and extend the Result class but this is already possible.

• [x] Are you creating a new feature?

  • [x] Why is the new feature needed? What purpose does it serve?
  • [x] How will users use the new feature?
  • [x] Base your feature on the develop branch, and submit against that branch.
  • [x] Add only one feature per pull request; split multiple features over multiple pull requests
  • [ ] Add tests for the new feature. => is this applicable?
  • [ ] Add documentation for the new feature. => is this applicable?
  • [x] Add a CHANGELOG.md entry for the new feature.

• [x] Is this related to quality assurance? Yes. Because my users are often confused by the generic error message when they can't log in

When using zend-authentication with ZF3, it seems that identity view helper requires that you register Zend\Authentication\AuthenticationService (literally) in your config file:

'service_manager' => [
        'factories' => [
            'Zend\Authentication\AuthenticationService' => Service\Factory\AuthenticationServiceFactory::class,
        ],
    ],

But, I expect that I should register this service with the ::class keyword, as follows:

'service_manager' => [
        'factories' => [
            Zend\Authentication\AuthenticationService::class => Service\Factory\AuthenticationServiceFactory::class,
        ],
    ],

However, this doesn't work. Is this a bug?

This PR adds feature to configure Authentication validator with user defined authentication result codes and their corresponding validation messages. Solves #41

• [x] Are you creating a new feature?
  • [x] Why is the new feature needed? What purpose does it serve? Authentication Result allows custom result codes to be specified but Authentication validator does not provide a way to map those codes to meaningful validation error messages. This feature fixes that by introducing new configuration option for Authentication validator.
  • [x] How will users use the new feature? New constructor configuration option code_map added. It is an array of [int $resultCode => string $validatorMessageKey]. Custom validator message key can be specified which is then registered as a new template that can be modified using common ways provided by Zend\Validator\AbstractValidator: setMessage() method or messages option.
  • [x] Base your feature on the develop branch, and submit against that branch.
  • [x] Add only one feature per pull request; split multiple features over multiple pull requests
  • [x] Add tests for the new feature.
  • [x] Add documentation for the new feature.
  • [x] Add a CHANGELOG.md entry for the new feature.

Fixes #13

• [x] Is this related to documentation? Old documentation for CredentialTreatmentAdapter provides md5() in its usage example which might prompt users to utilize insecure practices. This PR removes md5() usage from the documentation and adds further guidance towards CallbackCheckAdapter and PHP functions password_hash() and password_verify()

Zend\Authentication\Adapter\DbTable\AbstractAdapter allows only table name but not schema. Maybe it would be better to allow TableIdentifier instead of string?

Authentication validator is able to use adapter from the given AuthenticationService:

use My\Authentication\Adapter;
use My\Authentication\Storage;
use Zend\Authentication\AuthenticationService;
use Zend\Authentication\Validator\Authentication as AuthenticationValidator;

$adapter = new Adapter();
$storage = new Storage();
$service = new AuthenticationService($storage, $adapter);

$validator = new AuthenticationValidator([
    'service' => $service,
]);

$validator->setIdentity('username');
$validator->isValid('password');

It tears my soul that documentation about authentication mentions md5 so much. There is even an example how to use Autheticatin with md5. MD5 is insecure and todays RDBS support newer and secure methods.... (There is also md5 note in code comments)

https://docs.zendframework.com/zend-authentication/adapter/dbtable/credential-treatment/

This patch incorporates feedback provided on #14; I was unable to push to the author's repository, so I am instead opening a new pull request.

The patch incorporates all changes in #14, plus some changes recommended and/or required on review.

What the patch accomplishes is the ability for a Zend\Authentication\Validator\Authentication to use the authentication adapter in the composed AuthenticationService instance when:

• no adapter is present in the validator
• the adapter in the authentication service is a ValidatableAdapterInterface instance

This simplifies usage, as the consumer of the validator no longer needs direct access to the authentication adapter.

I'm looking for a way to check if my user really exists before I authenticate it.

Is this library capable of doing so or do I need to use \Zend\Ldap for this ?

It would be a pity if you need to use \Zend\Ldap as the serveroptions differ.

Authentication adapter and validator are the same. The authentication service provides input to adapter, which validates the identity and returns a result. With the proposed revision of Zend\Validator, we also have the ability to chain adapters and aggregate results which can be useful in Zend\Authentication. We could add these missing features to the Zend\Authentication component.

As adapters validate identity, they could be renamed to Validator or moved to Zend\Validator, which would make Zend\Authentication dependent on Zend\Validator ?

Currently, the content of Zend\Authentication\Result::identity is not clear if the result is not valid. Most of time, it returns null, but sometimes it returns an empty array, or the provided identity. The documentation says two different things about this:

getIdentity() returns the identity of the authentication attempt.

$identity is the value representing the authenticated identity. This may be any PHP type; typically you will see a string username or token, or an object type specific to the application or login module you utilize. When the result represents a failure to authenticate, this will often be null; some systems will provide a default identity in such cases.

So, on authentication failure, should the getIdentity() method always return the identity of the authentication attempt, or can it return whatever it wants? I think it should not return identity if the authentication fails, as this method is intended to provide identity to the storage on successful authentication.

To sum up, I would like the Zend\Authentication component to :

• Defines a Result interface modeling the results of authentication; it would compose the identity validated which will be use in authentication storage (only if authentication succeeded, otherwise it throws an error or returns null), authentication status, and, if present, any authentication error messages.
• Defines validators (adapters) which define a single validate() (authenticate()) method, accepting both a value and optional context, and return a Result instance.
• Defines a ResultAggregate interface for aggregating several results, as is necessary in a ValidatorChain (AdapterChain); Result instances would be pushed upon an aggregate.

What do you think of this proposal ?

Hello, for internal user authentication we will use LDAP Adapter and for external users the Zend DB Adapter. All external users uses the mail address as username. Also with the LDAP Adapter we will use the email address as username. We have more external than internal users.

1. How could the login login scheme look like?
2. LDAP as Fallback Adapter?
3. But how can we make sense that the LDAP also uses the mail address for the login? (first LDAP search and then bind with dn?)

class AuthenticationService extends ZendAuthenticationService implements AuthenticationServiceInterface
{
    /**
     * Authentication fallback adapter
     *
     * @var AdapterInterface
     */
    private $fallbackAdapter = null;

    /**
     * @param AdapterInterface $adapter
     * @return $this
     */
    public function setFallbackAdapter(AdapterInterface $adapter)
    {
        $this->fallbackAdapter = $adapter;
        return $this;
    }

    /**
     * @return AdapterInterface
     */
    public function getFallbackAdapter()
    {
        return $this->fallbackAdapter;
    }

    /**
     * @param AdapterInterface|null $fallbackAdapter
     * @return Result
     */
    public function fallbackAuthenticate(AdapterInterface $fallbackAdapter = null)
    {
        if (!$fallbackAdapter) {
            $fallbackAdapter = $this->getFallbackAdapter();
        }

        return $fallbackAdapter->authenticate();
    }

    /**
     * @return mixed
     */
    public function getIdentity()
    {
        if ($this->hasIdentity()) {
            $user = parent::getIdentity();
        } else {
            $user = new UserEntity();
            $user->setId(0);
            $user->setUsername('Gast');
            $user->setRole('guest');
        }

        return $user;
    }

}

@heiglandreas

i'm trying to implement multi servers ldap authentication mentioned in docs, the thing is auth process is flawless but with adding group to options parameters i get this: [0] => Account is not a member of the specified group [1] => Failed to verify group membership with (&(&(cn=grpTest)(grpTest=CN=Hamed Okhovvat,OU=IT,DC=Domain,DC=local))(objectClass=groupOfUniqueNames))

Is there any recommendation to verify group membership? Thanks a lot in advance

Hello. I wanted to ask, if there is a specific reason why authenticate() method also writes data to a storage? In ZF1 adapter only returned a result, which I think was the best possible solution. I think AuthService should only check data and prepare subclasses for further actions. In most cases, user won't need default identity but custom data. And now, if data is saved, it might cause bug ZF-7546 to re-appear. To prevent it, one should once again call clearIdentity() and write again after checking isValid().

As an example, possible bug code scenario - time window logins. User can only login during 8 -16. Because of some extra blocking inside !isValid(), we treat it as valid authentication and made some extra redirects if time didn't match. Now if we forget to clear identity before redirecting, MVC identity plugin will return true. Which may then lead to another bugs if we expected array and identity is a string.