[Security] [Firewall] Configuring multiple HTTP authentication methods

[SimonSimCity]

Hi,

I would like to discuss the possibility of how to improve the outcome of a failing authentication process.

I saw, that the two http-authentication methods for basic and digest authentication have their own AuthenticationEntryPoint where each of them creates a response, sets the corresponding response-header and returns a 401 status-code.

All this is correct. But if you define both, the basic and the digest authentication, just one of their AuthenticationEntryPoint classes will be called on a failing login and the client does not get informed about it.

In the first answer of http://stackoverflow.com/questions/3576197/http-authentication-www-authenticate-header-multiple-realms I read, that it's possible to return a set of possible authentication methods to be used, and the clients responsibility now is to take the most secure one it supports.

Now I tried to activate both, http_basic and http_digest authentication methods, and it just failed ... here's the error-message:

ContextErrorException: Catchable Fatal Error: Argument 4 passed to Symfony\Component\Security\Http\Firewall\DigestAuthenticationListener::__construct() must be an instance of Symfony\Component\Security\Http\EntryPoint\DigestAuthenticationEntryPoint, instance of Symfony\Component\Security\Http\EntryPoint\BasicAuthenticationEntryPoint given, called in /var/www/sf2.local/app/cache/dev/appDevDebugProjectContainer.php on line 2912 and defined in /var/www/sf2.local/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener.php line 40

    in /var/www/sf2.local/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener.php line 40
    at ErrorHandler->handle('4096', 'Argument 4 passed to Symfony\Component\Security\Http\Firewall\DigestAuthenticationListener::__construct() must be an instance of Symfony\Component\Security\Http\EntryPoint\DigestAuthenticationEntryPoint, instance of Symfony\Component\Security\Http\EntryPoint\BasicAuthenticationEntryPoint given, called in /var/www/sf2.local/app/cache/dev/appDevDebugProjectContainer.php on line 2912 and defined', '/var/www/sf2.local/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener.php', '40', array('securityContext' => object(SecurityContext), 'provider' => object(ChainUserProvider), 'providerKey' => 'secured_area')) in /var/www/sf2.local/vendor/symfony/symfony/src/Symfony/Component/Security/Http/Firewall/DigestAuthenticationListener.php line 40
    at DigestAuthenticationListener->__construct(object(SecurityContext), object(ChainUserProvider), 'secured_area', object(BasicAuthenticationEntryPoint), object(Logger)) in /var/www/sf2.local/app/cache/dev/appDevDebugProjectContainer.php line 2912
    at appDevDebugProjectContainer->getSecurity_Firewall_Map_Context_SecuredAreaService() in /var/www/sf2.local/app/bootstrap.php.cache line 2033
    at Container->get('security.firewall.map.context.secured_area') in /var/www/sf2.local/app/cache/dev/classes.php line 2758
    at FirewallMap->getListeners(object(Request)) in /var/www/sf2.local/app/cache/dev/classes.php line 2418
    at Firewall->onKernelRequest(object(GetResponseEvent), 'kernel.request', object(TraceableEventDispatcher))
    at call_user_func(array(object(Firewall), 'onKernelRequest'), object(GetResponseEvent), 'kernel.request', object(TraceableEventDispatcher)) in /var/www/sf2.local/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Debug/TraceableEventDispatcher.php line 392
    at TraceableEventDispatcher->Symfony\Component\HttpKernel\Debug\{closure}(object(GetResponseEvent), 'kernel.request', object(ContainerAwareEventDispatcher))
    at call_user_func(object(Closure), object(GetResponseEvent), 'kernel.request', object(ContainerAwareEventDispatcher)) in /var/www/sf2.local/app/cache/dev/classes.php line 1747
    at EventDispatcher->doDispatch(array(object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure), object(Closure)), 'kernel.request', object(GetResponseEvent)) in /var/www/sf2.local/app/cache/dev/classes.php line 1680
    at EventDispatcher->dispatch('kernel.request', object(GetResponseEvent)) in /var/www/sf2.local/app/cache/dev/classes.php line 1844
    at ContainerAwareEventDispatcher->dispatch('kernel.request', object(GetResponseEvent)) in /var/www/sf2.local/vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Debug/TraceableEventDispatcher.php line 139
    at TraceableEventDispatcher->dispatch('kernel.request', object(GetResponseEvent)) in /var/www/sf2.local/app/bootstrap.php.cache line 2900
    at HttpKernel->handleRaw(object(Request), '1') in /var/www/sf2.local/app/bootstrap.php.cache line 2883
    at HttpKernel->handle(object(Request), '1', true) in /var/www/sf2.local/app/bootstrap.php.cache line 3022
    at ContainerAwareHttpKernel->handle(object(Request), '1', true) in /var/www/sf2.local/app/bootstrap.php.cache line 2303
    at Kernel->handle(object(Request)) in /var/www/sf2.local/web/app_dev.php line 28

Any comments on that? I, personally, think this should be fixed and the code should be rethought to come up with a way, where I can activate both authentication-methods and I get both as possible methods to authenticate on a 401-response.

[SimonSimCity]

Just as a hint if you need it: It is kind of possible, yea ...

If you have the full project secured by multiple challenges, you can create your own listener, that listens on KernelEvents::EXCEPTION and catches all exceptions that are an instance of Symfony\Component\Security\Core\Exception\AuthenticationException. Just keep the priority of your listener above 0.

Here's an example:

    public function onKernelException(GetResponseForExceptionEvent $event)
    {
        static $handling;

        if (true === $handling) {
            return false;
        }

        $request = $event->getRequest();

        $handling = true;

        $exception = $event->getException();

        $yourChallenge = 'Basic realm="basic", Newauth realm="newauth"';
        if ($exception instanceof AuthenticationException) {
            $exception = new UnauthorizedHttpException($yourChallenge, 'You are not authenticated', $exception);
            $event->setException($exception);
            parent::onKernelException($event);
        }

        $handling = false;
    }

Please also take a look at this website, where you can see a list of supported challenge-combinations: http://greenbytes.de/tech/tc/httpauth/ None of the browser really keeps the spec here ;)

EDIT:
Please keep in mind, that this sample implementation is for your whole API! Not just the ones you put under your authentication. If you just want to have this triggered if the service does not provide it's own AuthenticationFailureHandler, keep the priority under 0.

[weaverryan]

If you have 2 auth methods and you want to control the "entry point" (i.e. the response sent back to the user to say "hey, you need to authenticate"), you can do this by setting your own "entry point" via the entry_point configuration under a firewall: http://symfony.com/doc/current/reference/configuration/security.html. Just create a class that implements AuthenticationEntryPointInterface, register it as a service, and put the id there:

security:
    firewalls:
        some_firewall_name:
            # ...
            entry_point: service_id_to_entry_point

I think this is the correct solution - there's no way we could automatically create 1 entry point Response for multiple authentication providers).

I hope this helps someone :).

[kgilden]

I would like to work on resolving this. Yep, @weaverryan's suggestion works. However, wouldn't it be nice to simply configure both HTTP Basic and HTTP Digest and have them just work? Possible use cases seem few and far in between except for feature completeness. Another one would be to provide a graceful way to migrate from one method to the other (i.e. for REST API-s).

security:
  firewalls:
    main:
      http_basic: ~
      http_digest:
        secret: '%secret%'
        realm: my-realm

These authentication methods can in theory coexist. So I was thinking of writing some glue code to basically use a facade for the two entry point classes along the following lines:

class HttpAuthenticationEntryPoint implements AuthenticationEntryPointInterface

    // [...]

    /**
     * {@inheritdoc}
     */
    public function start(Request $request, AuthenticationException $authException = null)
    {
        $responseForDigest = $this->digest->start($request, $authException);
        $responseForBasic = $this->basic->start($request, $authException);

        $responseForDigest->headers->set('WWW-Authenticate', [
            $responseForDigest->headers->get('WWW-Authenticate'),
            $responseForBasic->headers->get('WWW-Authenticate')
        ]);

        return $responseForDigest;
    }

    // [...]
}

I have a working proof-of-concept so it seems doable. Would this be considered a valid fix? Also, could this by any chance be merged with 2.8?

[kgilden]

ping @stof

[chalasr]

This is a bug that should be fixed.
For instance, configuring guard along with http_digest breaks, because the default entry point for the firewall is automatically the guard authenticator, which is not a DigestAuthenticationEntryPoint.
We do create the entry point if there is no default entry point configured, so we should keep creating it if the default one is not an instance of DigestAuthenticationEntryPoint.
Related to lexik/LexikJWTAuthenticationBundle#384.

[chalasr]

In fact, the entry point needs to be configured at the firewall level, there is no kind of per-listener entry point.

The current behavior is: if no entry_point configured at the firewall root level, then the first listener which registers an entry point is the one defining the firewall entry point.

So, Ryan's answer is the correct one. If you are using multiple listeners and at least one of them define an entry point but another (or your firewall) needs a specific entry point, you need to register the entry point as a service and make it the firewall entry point explicitly.

Here is how I solved it for this specific case (digest requiring specific entry point):

# security.yaml
firewalls:
    main:
        pattern:   ^/
        entry_point: app.digest_entry_point
        http_basic: ~
        http_digest:
            realm:    "%app.digest_realm%"
            secret:   "%kernel.secret%"

services.yaml
    app.digest_entry_point:
        class: Symfony\Component\Security\Http\EntryPoint\DigestAuthenticationEntryPoint
        arguments:
            - '%app.digest_realm%'
            - '%kernel.secret%'

Hope it helps, there is nothing we can do here.