The UserProvider: Custom Logic to Load Security Users

Hey Vladimir Z.!

I'd definitely recommend using the Guard authentication system, but you can certainly do whatever you want :). But with JWT, there is no session: you're just validation the token on each request and decoding it to get some user information. You could honestly put this all into a service and then call that service from anywhere (e.g. a controller). You would then be completely avoiding Symfony's security system, for better or worse (i.e. you would not appear to be "authenticated" to Symfony). That service class would look something like this:

class JWTAuthManager
{
    public function getUser()
    {
        // inside, you would read the JWT from the Request object, verify it and decode it
        // you could then use the information from the JWT to fetch the User object from
        // the database and return it
    }
}

Again, I recommend using Guard. But ultimately, verifying a JWT, decoding it, and using the information on it is a pretty simple task. You could then make decisions based on the User. You could also move all of the verifying/decoding to a listener on kernel.request so that it happens automatically on each request. You would then set the User object on a service so that you could fetch it easily later. That would also make sending back error JSON responses (e.g. for an invalid JWT) easier.

Cheers!

Thank you, Ryan!

hahaha that's funny ;)

Hey Simon,

What's your OS? Windows? I had the same problem on Windows, opening a DB connection was always taking about 1s and I had response time over 1s (I used to use OpenServer). Btw, you can debug what exactly consumes a lot of this response time with Symfony's Web Debug Toolbar - just click on this time icon and you will see Performance section with a nice Execution timeline. Find your bottle neck there, I bet it's something like DB connection, etc. which is not related to PHP scripts execution.

Cheers!

Nice job! It's actually quite different than the *old* "User Provider" chapter we had for Symfony2. Not a lot of has technically changed, but the way I like to explain it has :).

Cheers!

Hey Léo!

Ah, I missed this message! And it's a really good question. The reason is because of this "hide_user_not_found" option under security: http://symfony.com/doc/curr.... This makes it so that when we throw a UsernameNotFoundException, it turns it into a different exception. Here's the code for that: https://github.com/symfony/...

There's a bit more behind the scenes to controlling the exception messages in Symfony, and it's something that's been improved in Symfony 2.8 so that you have more control via a class called CustomUserMessageAuthenticationException: https://github.com/symfony/....

Cheers!

Yo Mike P.!

Very good! That *is* the correct way to handle it! We have a blog post about this stuff, if you want a bit more background: https://knpuniversity.com/b.... Either code will work in 3.2-3.4, but only the updated code will work in 4.0 and beyond.

Cheers!

Hi there!

This message can only be displayed because of 1 reason: your User class implements AdvancedUserInterface and the isAccountNonLocked() method returns false. Make sure this returns *true* for the User. I know, it has a confusing name "non-locked" is kind of a double negative. Anyways, here's the spot in the core that calls this method and gives you that error: https://github.com/symfony/...

Cheers!

Hello, I works! It was due to the isAccountNonLocked() which was set to false!

Thanks

Hi James!

That's really interesting! It appears that you logged in... but somehow are missing your User class. There's probably some tiny issue somewhere. Let's check out a few things:

1) What does the getUsername() method look like in your User class? If there is some bug in this, and it's returning a blank string, then I think it might cause this problem :).

2) If you hover over the icon in the web debug toolbar, what does it say for "Token class"? What about "Logged in as" - is that just blank?

3) If you turn intercept_redirects temporarily back to true and login, does the web debug toolbar look any different before you actually redirect?

4) After logging in, go into your favorite controller and run this code:

dump($this->get('security.token_storage')->getToken());die;

Basically, you're getting logged in, but something is wrong with the User class, which is inside of this "Token" class. The above dump would tell us more info about what's going on.

Let me know what you find out!

Yes found it just a few minutes ago, I forgot some private fields in LoginFormAuthenticator... My bad!

Thanks anyway for the lightning fast answer!

Sweet! Catching your own errors? No better way to learn something :). Cheers!

Hey Patrick,

In case you're going to use a Symfony Guard authenticator - it has a fancy method to helps with it, see supportsRememberMe(): https://github.com/symfony/...

Also, look at "always_remember_me: true" option: https://symfony.com/doc/cur...

Cheers!

Hi victor

Thanks for the information - that's really helpful!

I'd missed the "always_remember_me: true" option - that looks like just what I'm looking for!

Is there a way to enable "always_remember_me: true" for just one (Guard) authenticator? So that, for example, you could have a FacebookAuthenticator which always set remember_me to true, but you had a GoogleAuthenticator which (for some reason) didn't set remember_me automatically?

Thanks again!

Hey Patrick!

Hmm. So, it's not exactly possible, because always_remember_me is at the firewall level. You could of course create multiple firewalls, but that's taking a hammer to the situation :).

But, the way that remember me NORMALLY knows that it should be activated, is by looking for a _remember_me checkbox in your form. So, you could add that to one form, but not the other. Or... you can even be a bit sneakier :). Even without that checkbox, I think (never tried before, but 99% sure) that you could set this value into the request, from inside your authenticator (could be anywhere):

$request->attributes->set('_remember_me', true);

That should activate it :).

Cheers!

Hey ahmedbhs!

Yes, absolutely! In fact, it's very easy, but a little bit confusing :). Basically, Symfony forces you to use a "username" in a few places: in your User class, you must have a getUsername() method. And in your user provider, you must have a loadUserByUsername method.

But.... if you want don't want a username, and instead just want an email, then simply make both of these methods work with an email instead. What I mean is, in User::getUsername(), return $this->email And in loadUserByUsername, query the database via your email field. Symfony is using the term "username"... but really, "username" is whatever unique thing you want - the "username", an email, a uuid or whatever.

Cheers!

Hey Mark,

A lot of autocompletion for Symfony Framework comes from Symfony Plugin for PhpStorm, see https://knpuniversity.com/s... where we show how to install and configure it.

Cheers!

Have been running this the entire series, but cannot get yaml autocomplete to work :-( Tryed googling around a bit, but couldn't get an answer on how to "enable" really.

Hm, probably it also depends on your PhpStorm / Symfony Plugin versions... but not all the yaml files could have autocomplete. It works mainly for app/config/config.yml. Go to PhpStorm preferences and find Symfony Plugin preferences - make sure you tick all the necessary checkboxes and enabled the plugin. Sometimes it may just stop working, especially after some internal PhpStorm errors, but after upgrade to the latest versions and PhpStorm restart it works again.

Cheers!

I found it, in symfony3 no longer requires to implement "UserProviderInterface" instead it needs to implement "UserLoaderInterface"

Yes, good find! We changed that in Symfony 2.8 - the new interface is a little bit easier than the old one. DX improvement... as long as you know it exists :). Thanks for posting your solution!

No problem, I hope someone find this useful

Hey Dominik!

We are glad that you are liking our tutorials :)

Could you show me how looks like your security.yml and config.yml files?
Also what symfony version are you using ?

Have a nice day!

Thanks for your help. Here we go:

Symfony 3.1.4 - app - dev
PHP 5.5.38 - no cache or APC
i use the build in web server like in the tutorials.

uhm .. perhaps this is the problem?
<cite>PHP needs to be a minimum version of PHP 5.5.9</cite>
The PHP versions seems to be little bit old on this machine cought

or perhaps missing serialize functions in the authenticator?

security.yml:
i needed the : notation for the entity to get the auth working at all.

# To get started with security, check out the documentation:
# http://symfony.com/doc/current/book/security.html
security:

    # http://symfony.com/doc/current/book/security.html#where-do-users-come-from-user-providers
    providers:
        our_users:
            entity: { class: AppBundle:User, property: email }

    firewalls:
        # disables authentication for assets and the profiler, adapt it according to your needs
        dev:
            pattern: ^/(_(profiler|wdt)|css|images|js)/
            security: false

        main:
            anonymous: ~
            guard:
                authenticators:
                    - app.security.login_form_authenticator

            # activate different ways to authenticate

            # http_basic: ~
            # http://symfony.com/doc/current/book/security.html#a-configuring-how-your-users-will-authenticate

            # form_login: ~
            # http://symfony.com/doc/current/cookbook/security/form_login_setup.html

config.yml:
the different locale is not the problem

imports:
    - { resource: parameters.yml }
    - { resource: security.yml }
    - { resource: services.yml }

# Put parameters here that don't need to change on each machine where the app is deployed
# http://symfony.com/doc/current/best_practices/configuration.html#application-related-configuration
parameters:
    locale: de
    cache_type: file_system

framework:
    #esi:             ~
    translator:      { fallbacks: ["%locale%"] }
    secret:          "%secret%"
    router:
        resource: "%kernel.root_dir%/config/routing.yml"
        strict_requirements: ~
    form:            ~
    csrf_protection: ~
    validation:      { enable_annotations: true }
    #serializer:      { enable_annotations: true }
    templating:
        engines: ['twig']
        #assets_version: SomeVersionScheme
    default_locale:  "%locale%"
    trusted_hosts:   ~
    trusted_proxies: ~
    session:
        # handler_id set to null will use default session handler from php.ini
        handler_id:  ~
        save_path:   "%kernel.root_dir%/../var/sessions/%kernel.environment%"
    fragments:       ~
    http_method_override: true
    assets: ~

# Twig Configuration
twig:
    debug:            "%kernel.debug%"
    strict_variables: "%kernel.debug%"
    number_format:
        thousands_separator: '.'
    form_themes:
        - bootstrap_3_layout.html.twig

# Doctrine Configuration
doctrine:
    dbal:
        driver:   pdo_mysql
        host:     "%database_host%"
        port:     "%database_port%"
        dbname:   "%database_name%"
        user:     "%database_user%"
        password: "%database_password%"
        charset:  UTF8
        # if using pdo_sqlite as your database driver:
        #   1. add the path in parameters.yml
        #     e.g. database_path: "%kernel.root_dir%/data/data.db3"
        #   2. Uncomment database_path in parameters.yml.dist
        #   3. Uncomment next line:
        #     path:     "%database_path%"

    orm:
        auto_generate_proxy_classes: "%kernel.debug%"
        naming_strategy: doctrine.orm.naming_strategy.underscore
        auto_mapping: true

doctrine_cache:
    providers:
        my_markdown_cache:
            type: %cache_type%
            file_system:
                directory: %kernel.cache_dir%/markdown_cache

and my LoginFormAuthenticator because i have to use the new onAuthenticationSuccess function

<?php

namespace AppBundle\Security;


use AppBundle\Form\LoginForm;
use Doctrine\ORM\EntityManager;
use Symfony\Component\Form\FormFactoryInterface;
use Symfony\Component\HttpFoundation\RedirectResponse;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Routing\RouterInterface;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Http\Util\TargetPathTrait;
use Symfony\Component\Security\Core\Exception\AuthenticationException;
use Symfony\Component\Security\Core\User\UserInterface;
use Symfony\Component\Security\Core\User\UserProviderInterface;
use Symfony\Component\Security\Guard\Authenticator\AbstractFormLoginAuthenticator;

class LoginFormAuthenticator extends AbstractFormLoginAuthenticator
{
    /**
     * @var FormFactoryInterface
     */
    private $formFactory;
    /**
     * @var EntityManager
     */
    private $em;
    /**
     * @var RouterInterface
     */
    private $router;

    function __construct(FormFactoryInterface $formFactory, EntityManager $em, RouterInterface $router)
    {
        $this->formFactory = $formFactory;
        $this->em = $em;
        $this->router = $router;
    }

    public function getCredentials(Request $request)
    {
        $isLoginSubmit = $request->getPathInfo() == '/login' && $request->isMethod('POST');
        if (!$isLoginSubmit) {
            return;
        }

        $form = $this->formFactory->create(LoginForm::class);
        $form->handleRequest($request);
        $data = $form->getData();

        return $data;
    }

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

        return $this->em->getRepository('AppBundle:User')
            ->findOneBy(['email' => $username]);
    }

    public function checkCredentials($credentials, UserInterface $user)
    {
        $password = $credentials['_password'];

        if ($password == 'iliketurtles') {
            return true;
        }

        return false;
    }

    protected function getLoginUrl()
    {
        return $this->router->generate('security_login');
    }

    use TargetPathTrait;

    public function onAuthenticationSuccess(Request $request, TokenInterface $token, $providerKey)
    {
        // if the user hits a secure page and start() was called, this was
        // the URL they were on, and probably where you want to redirect to
        $targetPath = $this->getTargetPath($request->getSession(), $providerKey);

        if (!$targetPath) {
            $targetPath = $this->router->generate('homepage');
        }

        return new RedirectResponse($targetPath);
    }


}

It seems that i have solved the problem.

I updated my PHP to 5.6.30
I had to change the provider entity class name back to AppBundle/Entity/User for the login to work again.
But i still got logged out again after a refresh.

After that i run "composer update" to update the packages and dependencies.
Now Symfony is running at version 3.1.10 and I finally stay logged in. Hooray!

Setting my the course to "Logout" tutorial now .. lol :-)

Hey Dominik!

Sorry for the late response, I'm glad you could fix your problem without my help, you defenitely had a weird one ;)

Cheers!

Hey Carlos!

Oh boy, the user provider is very confusing. First, you don't implement UserProviderInterface in the User entity - the User entity implements UserInterface. So, the User and your "user provider" are 2 separate things. But, what you said about the UserProvider is true: it allows you to use remember me functionality, save user to the session and do impersonation. And, in practice, all authentication systems *must* have a User Provider. So, it's a necessary part of your system, but many people don't even realize it exists or what it does. If you're using Doctrine and your User class is an entity, then you've probably configured the "entity" user provider in security.yml under the "providers" key (http://symfony.com/doc/curr.... Doing that is enough to configure a user provider that does all of the things you mentioned. I think it should be quite rare that you need a custom user provider.

I hope this helps! It *is* confusing!

Ah, I understood.
We use the Symfony default user provider. Indicated in security.yml.

Could you tell me a case where a custom user provider really needs it?
Thanks Ryan

Hey Carlos!

Originally, people used the user provider inside of their authentication system in order to load their users. In fact, for many of the built-in authentication mechanisms, like form_login, http_basic, etc, this is still true: you submit a username + password form, and the form_login authentication mechanism uses your user provider (e.g. the entity provider) to know where to load that User. So, if you're using one of these mechanisms, and you need to load your users from a different location (perhaps your User information is stored across an API), you'll need a custom user provider.

However, thanks to Guard, I recommend now that people use it to create their own authentication mechanisms whenever they have any non-standard situation (a login form that loads from the database is standard, so using form_login is fine). In Guard, you are in complete control of loading your User object however you want (in your getUser() method), and I recommend for clarity, not using your user provider to do this work. Instead, for example, if you need to load User information from some API, then just write the code in your authenticator and do it! In this situation, when would you need a custom user provider? Well, remember, a user provider does basically 2 things:

A) It refreshes the User from the session (UserProviderInterface::refreshUser(UserInterface $user)
B) It loads a user by username for remember_me and switch_user (UserProviderInterface::loadUserByUsername($username))

So, you'll need a custom user provider basically if your User information is not stored in a database. If it is, just use "entity". If you do originally load User information from some other place (e.g. an API) but then save a new User database record for each user, then you should still use the entity provider. A custom provider is needed only if your User object can only be populated by loading data from some custom (i.e. non-database) source.

So, in theory, it's not SO uncommon... but I rarely see it: almost always, people are loading users from a database. Even if they have some big central-authentication system, they often store a local User object in their database so that they can store application-specific information about that User. And as I mentioned, if this is the case, you should still use the entity provider.

I hope this helps! The user provider is unfortunately confusing in Symfony, which is why I try to minimize how much people worry about it. In 99% of the use-cases, you should configure the "entity" provider in security.yml and never think of it again :).

Cheers!

Hi Ryan, excuse me again ... =(

I have a question with this subject.

In my application I use the default Provider Entity of symfony, (I have not created a user provider).

I want to use the bundle fos oauth server https://github.com/FriendsOfSymfony/FOSOAuthServerBundle/blob/master/Resources/doc/index.md

I imagine that you have used it sometime =)

The documentation says:

• If you're authenticating users, don't forget to set the user provider. Here's an example using the FOSUserBundle user provider:

#config.yml
fos_oauth_server
    service:
        user_provider: fos_user.user_provider.username

For this case, I enter the doubt written in my previous comments,
In this case, I need to create my non-user provider?

Regards Ryan, thank you very much

Hi Carlos!

I have not actually used this bundle yet, but I think I can answer your question :). And, I can understand the confusion - it wasn't clear to me why this was needed in that bundle! So, It did a little bit of digging!

It turns out, that the user provider is only needed by that bundle if you allow the "password" grant type (also called user credential grant type) to be used to get a token. In this model, your user sends their username and password directly to the server. IF you use this grant type, then the bundle calls the loadUserByUsername method on your user provider (https://github.com/FriendsOfSymfony/FOSOAuthServerBundle/blob/master/Storage/OAuthStorage.php#L161) to fetch the user. So, you would only need a custom user provider if, for example, you allowed your users to send something other than a username (e.g. their "id") - you would then need a user provider whose loadUserByUsername() expects the $username to actually be an id, and then fetches the user by id.

I hope that helps! If you don't set the user provider in the configuration for that bundle, I believe you won't have any problems, unless you try to use this grant type.

Cheers!

Hi Paul-André!

Unfortunately, I don't know a lot personally about LDAP. But, I do know a lot about Guard, so I'll do my best to help :).

1) Since you're using Guard, obviously you need to do a little bit more work yourself in the authenticator (which is ok, because you also get a lot more flexibility). But, we can use the built-in LDAP authentication classes as inspiration for what we do. For example, the form_login_ldap authentication listener, is actually this class: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Authentication/Provider/LdapBindAuthenticationProvider.php. So, how should you check the users password? Mimic was it's doing here: https://github.com/symfony/symfony/blob/master/src/Symfony/Component/Security/Core/Authentication/Provider/LdapBindAuthenticationProvider.php#L71. Specifically, the $this->ldap library is your app.security.ldap service. So this is what you should inject into your authenticator.

2) And yes, I noticed your "chain" user provider. User providers can be complex to understand, and we definitely have a problem here. First, make sure you review this: http://knpuniversity.com/screencast/symfony-security/user-provider - it tries to explain the purpose of the user provider. Your exact correct setup depends on your needs. So, I'm going to ask a bunch of questions:

As I understand it, your users should be able to login via their LDAP credentials or by logging in with their username/password that is stored in the database. Is this correct? Do you also have 2 different user classes? And, will you need to store application information about all users, or is the purpose for the users ONLY to be able to login? Will some users only exist in the database, but not in LDAP? And will some where only exist in LDAP and not in our local database? If a user exists in the database, but not in LDAP, will they thus manage their password in your system (instead of LDAP)? And if they exist in LDAP and not in your local database, I assume they will thus manage their password in LDAP and not your system? Or asked differently, is it true that some users will be logging in with their password in LDAP and other users will be logging in with their password that's manage by your system?

Pass me some more information and I should be able to help your get your providers worked out correctly! But remember this point about providers:

A) The point of a user provider is only to reload the user (e.g. from the database) at the beginning of each request. So, if ultimately - once the user has logged in - you have a local "user" record in your database for every user, then you only need the entity provider. Otherwise, yes, you'll need a chain provider like you have.

B) When the user is originally logging in, you are in 100% full control of how that works - via your getUser() method. You could absolutely first look for the user in LDAP (you'll need a try-catch around loadUserByUsername, since this throws a UsernameNotFoundException) and if it's not found, look for it in your database.

Cheers!

Hi Ryan,

First, Great, Great thanks for having me lead in the right direction... with the LdapBindAuthenticationProvider. I've extended that class in one of my own and adapted the things a bit to mimic the checkAuthentication method.
The main difficulties I encountered were at last with our AD authentication itself ;)

So, to help you helping me with the chain provider, here are answers to the list of questions:
* All the users of the application are stored in the database - our AD has got only the people who are still considered in activity in our institution - the AD has got thus only a subset of what is stored in the database. So, in the getUser method of my authenticator, I used only the EntityManager to get the corresponding user out of database.
* As the AD is responsible of authenticating the "active" users and as the users can modify their password through their windows desktop, my intention (and what I've done) was:
* if a user is authenticated against the AD, that meant his/her password was recognized... and that's ok... so in the checkCredentials method of my authenticator, I putted the call to the adapted checkAuthentication method in a try (as you suggested), and if it succeed, I return true.
* if a user is not authenticated against the AD, I try to find him/her in the AD with the loadUserByUsername method of the ldap client. If (s)he's found, I return false meaning the username was right but password not and if (s)he's not found, I check if password is valid against the database. If yes, the user is logged in, otherwise, it sends back false (and thus invalid credentials)

Concerning the update of password in the database, if the user succeed to login against the AD, I update (and encrypt) the password field of the user in the database.

So the moment I'm extending the LdapBindAuthenticatorProvider who needs a UserProviderInterface and the moment I'm playing with a user coming from database, I guess I need both of them in a ChainProvider... Am I right ?

Thanks again a hundred time for the help provided Ryan,

Kind regards,

Paul-André