form_login: El autentificador incorporado

First of all, thank you for your great job.
I have a question: at the beginning of this chapter you say: "Custom authenticator classes like this give us tons of control. Like, imagine that, in addition to email and password fields, you needed a third field - like a "company" dropdown menu... and you use that value - along with the email - to query for the User. Doing that in here would be... pretty darn simple! Grab the company POST field, use it in your custom query ...."
Do you think is also possible to use the "company" or similar field to prefix table names, including User tabel, as stated at https://www.doctrine-project.org/projects/doctrine-orm/en/2.16/cookbook/sql-table-prefixes.html ??
Thank you in advance for your help

Hey @Claudio-B ,

IMO the Doctrine DB prefixes feature is a completely standalone feature that is implemented via an event listener, so in theory yes, you can use that in this case if you need it. Unfortunately, I have never used that personally, so can't tell you for sure... but give it a try, I think it should work.

Cheers!

Hi there!

Which option is better for login form which will:

• authenticate the users from the database
• have forgot password option
• have remember me checkbox
• allow login with google, github and twitter

The custom authenticator class, or the built in LoginFormAuthenticator?

Thanks!

Hey @t5810

The LoginFormAuthenticator will work great for the first 3 items, but for social login, you'll have to integrate one of these third party bundles (or do it by yourself): KnpUOAuth2ClientBundle HWIOAuthBundle

Cheers!

Hello!
Awesome job with the Security course! I got a question - how can we add some password requirements using login_form? Eg. min and max len, requires at least one special character etc?
Thanks!

Hey Bartlomeij,

If you're using the Symfony Form component, you can create a custom form for your login page and add a field constraint to the password. Or, you can use the Validator component manually https://symfony.com/doc/current/components/validator.html

Cheers!

Hi there,
thanks for this wonderful introduction to the security system.

Everything works as expected with symfony's test server. As soon as I move the code to the hosting provider all redirects (after login or logout) go to "http" instead of "https". The .htaccess-file contains this snippet to send requests to index.php:
`
RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^ %{ENV:BASE}/public/index.php [L]

`

Then in framework.yaml I have to set
<br />assets:<br /> base_path: 'public'<br />

The following in .htaccess does not work
<br />RewriteCond %{HTTP:X-Forwarded-Proto} !https<br />RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI}<br />
It uses the full path as URL (including 'public/index.php') which looks ugly in the browser address-line, and the images are missing.
Thanks for a hint!

Hello,

could anybody help me please with using multiple authentifications providers? I need authenticate users first from local user database (App\Entity\User) and then from LDAP. When the user is not found in local database, then check from LDAP.

I have this security.yml
`security:

enable_authenticator_manager: true

# https://symfony.com/doc/current/security.html#registering-the-user-hashing-passwords
password_hashers:
    Symfony\Component\Security\Core\User\PasswordAuthenticatedUserInterface: 'auto'
    App\Entity\User:
        algorithm: auto

providers:
    app_user_provider:
        entity:
            class: App\Entity\User
            property: email

    ldap_user_provider:
        ldap:
            service: Symfony\Component\Ldap\Ldap
            base_dn: 'dc=ipp,dc=local'
            search_dn: 'cn=searchuser,cn=Users,dc=example,dc=com'
            search_password: 'password'
            default_roles: ROLE_USER    
            uid_key: userPrincipalName
            #extra_fields: ['mail', 'cn']

    chain_provider:
        chain:
            providers: ['app_user_provider', 'ldap_user_provider']

firewalls:
    dev:
        pattern: ^/(_(profiler|wdt)|css|images|js)/
        security: false

    main:
        lazy: true
        provider: chain_provider

        form_login:
            login_path: login
            check_path: login
            enable_csrf: true
        
        form_login_ldap:
            service: Symfony\Component\Ldap\Ldap
            login_path: login
            check_path: login
            dn_string: '{username}'

        logout:
            path: logout
            target: login

# Easy way to control access for large sections of your site
# Note: Only the *first* access control that matches will be used
access_control:
    # allow unauthenticated users to access the login form
    - { path: ^/login, roles: PUBLIC_ACCESS }
    
    - { path: ^/admin, roles: ROLE_ADMIN }
    
    - { path: ^/app, roles: ROLE_USER }`

Actually, users from form_login are successfully authenticated but, from LDAP not. When I comment form_login from main firewall, users should authenticate from LDAP, but not from local database.

Cheers

Hey Tomáš S.

You need to create a custom authenticator where you'll check the database first for the user's credentials, and in case it was not found, you'll use your Ldap service to fetch the user. Here are the details of how to write a custom authenticator: https://symfony.com/doc/cur...

Cheers!

Hello Diego,

thank you for your advice. Before when I start to creating a custom authenticator. Could you please explain me purpose of chain provider?

I have expected, when I set chain_provider like this:
`

    chain_provider:
        chain:
            providers: ['app_user_provider', 'ldap_user_provider']

</code >

then the application try to authenticate with app_user_provider first and when user is not found, then try second ldap_user_provider. Or I am wrong?

Thank you
Tomas

Yes, that's exactly the behavior of the ChainProvider, you can read more about it here: https://symfony.com/doc/cur...

Do you have multiple authenticators as well? If that's the case, then, I think you don't need a ChainProvider because each authenticator can implement the specific logic for finding users

Thank you for confirming ChainProvider behavior.

Multiple authenticators? I thnink yes, I have...

`form_login:

login_path: login
check_path: login
enable_csrf: true

form_login_ldap:

service: Symfony\Component\Ldap\Ldap
login_path: login
check_path: login
dn_string: '{username}'`

So what did you thing I have wrong in security.yml?

Oh, I think I see the problem. You're using the same login/check route on both cases. You need to use different ones, otherwise, Symfony will always use the first service declared (in this case, form_login)

Hey Diego,

Thank you for look at my problem. I try to change security.yml this way:`form_login:
login_path: login
check_path: login
enable_csrf: true

form_login_ldap:
service: Symfony\Component\Ldap\Ldap
login_path: login_ldap
check_path: login_ldap
dn_string: '{username}'`

but without success. The users are still validated only from local database, but not from LDAP.

There must be somewhere any different error...

Tomas

Hmmm, that's odd. Are you using different routes on each authenticator, right? I think I need to see your security.yaml file (preserving formatting). Is there a place where you can upload it?

Hello Diego,

Here is my security.yml uploaded...
http://ftp.intevia.cz/secur...

I you need, I can prepare new symfony applcation with this issue only and give you access to repo...

Cheers
Tomas

Hey man, I think I found your problem! and it's quite sneaky. Under your "access_control" key, you have defined a few paths, but those actually work as a REGEX, and the first path that matches is the winner. In your case, you have ^/login at the top, then you have your Ldap route ^loginldap/ - Can you see the problem here? Your first login route will always win (because of the REGEX thing)

Cheers!

Hello,
OK, I change paths to login

            form_login:
               login_path: login
               check_path: login
               enable_csrf: true

            form_login_ldap:
                service: Symfony\Component\Ldap\Ldap
                login_path: ldaplogin
                check_path: ldaplogin
                search_dn: 'cn=ldapuser,cn=Users,dc=example,dc=com'
                search_password: 'ldapuser_password'
                dn_string: '{username}'```


And under "access_control" like this:

    - { path: ^/login, roles: PUBLIC_ACCESS }
    - { path: ^/ldaplogin, roles: PUBLIC_ACCESS }```

But when I open the page /login, I cannot login from local database and from ldap too (any method does not work)
When I open the /ldaplogin page, I am able to log with local database user only, not from ldap.

Could I upload messages from profiler? I can make some printscreen...

That's interesting, I was not expecting that behavior. I believe your case fits into having multiple firewalls enabled, one for your login form, and another one for the Ldap form. Here's an example: https://symfony.com/doc/cur...

Hello,

In this example are two firewalls...But I have define entry points in one firewall.

# config/packages/security.yaml
security:
    # ...
    firewalls:
        api:
            pattern: ^/api/
            custom_authenticators:
                - App\Security\ApiTokenAuthenticator
        main:
            lazy: true
            form_login: ~

    access_control:
        - { path: '^/login', roles: PUBLIC_ACCESS }
        - { path: '^/api', roles: ROLE_API_USER }
        - { path: '^/', roles: ROLE_USER }

My goal is to have ONE page for login and use chain_provider. So if the user is not found in local database, then try ldap.

I try to make example application.

Cheers
Tomas

Hey Diego,

I have created a repository where is everything described. Here is https://github.com/skocdopo...

Now it should be everything clear for you.

Thank you

Hey Tomáš S.!

I noticed your message before Diego did today ;). Thanks for. the repository, that's very helpful. I understand what you're trying to do... and it's oddly complex. With the setup in the repo, what will happen is when you submit the login form, either form_login OR form_login_ldap will FIRST try to authenticate the request. Let's assume form_login is first. If you log in using a user in your database, I bet it will work.

But if you login with a user that's only in LDAP, it will fail, throw an authentication error and NEVER try form_login_ldap.

So... does having the "chain provider" help with this? MAYBE, and this is where my limited knowledge of LDAP comes into play. In theory, when form_login is processing, if it can't find the user in the database, it would then go find it in ldap thanks to the chain provider. Then, effectively, Symfony will call $user->getPassword() on that LdapUser and compare it to the submitted password. And so, in theory, if the password is being loaded from LDAP, this should work. However, I don't think this is the standard way of checking LDAP passwords (I believe this is the standard way: https://github.com/symfony/symfony/blob/f3ec7a0238c2503f1f653c23344660575160ebb6/src/Symfony/Component/Ldap/Security/CheckLdapCredentialsListener.php#L99 ).

So... it might work with a chain provider and form_login only? But I'm not sure... and it seems weird to me. Also, even if you got this working, it would mean that, if the user logs in and is in the database, then the logged in user is App\Entity\User. If the user is in Ldap, it is Symfony\Component\Ldap\Security\LdapUser... which gets weird, because you can't use any custom methods that you have inside of App\Entity\User reliably.

A more common flow that I've seen works like this:

A) You ALWAYS authenticate against LDAP... because that's where user passwords are stored.
B) After login, you load or create a User entity to correspond to this LDAP user.
C) Then, you. are finally logged in AS the Entity User.

I would probably do this via a custom authenticator using https://github.com/symfony/symfony/blob/f3ec7a0238c2503f1f653c23344660575160ebb6/src/Symfony/Component/Ldap/Security/CheckLdapCredentialsListener.php as inspiration for doing the LDAP logic.

But, i'm assuming a lot, so that's enough for now. Let me know if this is helpful :).

Cheers!

Hi Ryan,

Thank you for your very comprehensive answer.

The LDAP authentication is performed using two connections. First connection is created (using the search_dn and search_password parameters from the configuration) to query whether the user exists in the LDAP database. If the given user is found, a second connection is established (using the given user and his password) for check a password. If connection is successfully established, it means that the password is correct. Then is the user successfully authenticated!

I know it's probably best to do the mechanism you're proposing, but in this case I don't need to store logged-in users in a local database...

But I have lot of questions about chain_provider. Why is it implemented at all? What is its purpose?

I mean, isn't this a symfony bug?

Sincerely, Thomas

Hey @Thomas!

I actually very much appreciate that description of LDAP. I get questions about it somewhat frequently, but have never needed to use it directly myself. Great explanation!

> But I have lot of questions about chain_provider. Why is it implemented at all? What is its purpose?

The user provider, in general, has 2 purposes:

A) It's used to "load the user" for some features like switch_user and remember_me (e.g. take the "username" from the cookie and find that User).

B) Most "authentication mechanisms" (though not a requirement) use this to "load the user" during authentication. For example, form_login and, I think, form_login_ldap use this. However, different authentication mechanisms then have totally different ways for checking the password. And THAT is the part that's causing you trouble.

> I mean, isn't this a symfony bug?

Things are working as designed. However, I DO think that what you're trying to accomplish should be less trouble.

> I know it's probably best to do the mechanism you're proposing, but in this case I don't need to store logged-in users in a local database...

Ah, that's no problem! I was guessing some things about your implementation before, but let me rephrase them. Create a custom authenticator that:

A) Pass the email/username to the UserPassport. That's all your need to do. If you're using the chain provider, then the User will be found in your normal user provider or ldap.
B) For credentials, pass a CustomCredentials. In the callback you pass this, the 2nd argument will be the User object that was found (first will be the submitted password). Based on whether the user was found in the database vs in LDAP, you will have one of two different classes (your entity or a core LdapUser). If normal User, check the password (inject the user password checker service). If Ldap, try to bind the password as you described.

You're still going to be building some things by hand and doing more work than you should need to, but this general plan should work. Let me know what you think - I'm still doing some guessing on your requirements. Also, it IS weird that some users will be logged in via one User class and others via a different LdapUser. That's allowed... but you won't be able to call any methods that both of these do not share.

Cheers!