8000 Document security pitfall when using multiple user providers and user specific authenticators · Issue #8611 · symfony/symfony-docs · GitHub
[go: up one dir, main page]

Skip to content

Document security pitfall when using multiple user providers and user specific authenticators #8611

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
xabbuh opened this issue Nov 10, 2017 · 6 comments
Labels
hasPR A Pull Request has already been submitted for this issue. Security

Comments

@xabbuh
Copy link
Member
xabbuh commented Nov 10, 2017

When creating your own authenticator (probably by using Guard) and you have more than one user provider, one needs to take extra caution when it comes to different authentication based on the way users are loaded.

For example, if you combine https://symfony.com/doc/current/security/multiple_user_providers.html and http://symfony.com/doc/current/security/guard_authentication.html you will probably want to check that you only use the API token authenticator with appropriate users.

@javiereguiluz
Copy link
Member

I don't know how to solve this. Are you suggesting to add a $userProvider instanceof ApiUserProvider::class check somewhere inside getUser()? Thanks.

@xabbuh
Copy link
Member Author
xabbuh commented Nov 10, 2017

Usually, each user provider would probably support a different implementation of the UserInterface. Then, one could just check if said implementation is supported the authenticator.

@javiereguiluz
Copy link
Member

Thanks, but I still don't understand what to do. Maybe you can show me some code to add in some method of that example? Thanks!

@xabbuh
Copy link
Member Author
xabbuh commented Nov 10, 2017

Having a quick glance at the guard code I think we could add a caution block like this:

.. caution::

    If you are using multiple user providers, you will also need to check that the
    user being returned by the ``getUser()`` method of your provider is a allowed
    to authenticate using a token::

        // ...

        public function getUser($credentials, UserProviderInterface $userProvider)
        {
            $apiKey = $credentials['token'];

            if (null === $apiKey) {
                return;
            }

            $user = $userProvider->loadUserByUsername($apiKey);

            // you can, for example, test that the returned user is an object of a particular class
            // alternatively, you can also check for certain attributes of your user objects
            if (!$user instance ApiKeyUser) {
                return;
            }

            return $user;
        }

ping @chalasr @ogizanagi

@ogizanagi
Copy link
Contributor

Talking a bit with @chalasr: Not sure we need an extra caution block here. If you use an api token authentication, you're not likely to use the same provider. Users are not identified the same way (but it can be the very same user class).
Using a chain provider here is probably wrong in most cases and we should warn the user to properly think what provider should be used for his auth instead. WDYT?

@javiereguiluz javiereguiluz added the hasPR A Pull Request has already been submitted for this issue. label May 3, 2018
javiereguiluz added a commit that referenced this issue May 24, 2018
This PR was squashed before being merged into the 2.7 branch (closes #9726).

Discussion
----------

Improved the multiple user providers article

This tries to solve both #8582 and #8611. Please @xabbuh, @chalasr and @ogizanagi tell me if I did what you expected according to your comments in the related issues. Thanks!

Commits
-------

e0f483b Improved the multiple user providers article
@javiereguiluz
Copy link
Member

Fixed by #9726.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
hasPR A Pull Request has already been submitted for this issue. Security
Projects
None yet
Development

No branches or pull requests

3 participants
0