Suplantación: switch_user

Hey @SamuelVicent!

Sorry for the slow reply! Are those 2 different domains served by the same Symfony app? If you log into domain1.com, are you (under normal circumstances) logged into domain2.com?

Basically, if your answer to my 2nd question is "yes", then I would imagine that if you impersonate on domain1.com, you would automatically also be impersonated on domain2.com (the assumption here is that these domains are sharing a cookie - a fact that would only actually work if they were 2 subdomains of the same domain).

However, I have a feeling that the setup is not so simple and that these two domains are a bit more separated (i.e. if you log into domain1.com you are NOT automatically logged into domain2.com). If that's the case, impersonation won't work automatically and you'd need to set something up custom to make it happen - and I'm happy to brainstorm if that would be helpful :).

Cheers!

Hey Rufnex,

Could you elaborate a bit more on your question? I don't fully understand what you need. If you're talking about impersonation, any user that has the role ROLE_ALLOWED_TO_SWITCH will be able to impersonate anybody

Cheers!

Hi MolloKhan,

in the user provider this e.g. uses property: email as identifier. I need a second field (company_id) to identify the user. Can you give me an example for that?

(select .. from users where email = '...' and company_id = 123)

Ok, in that case you'll need to load your users manually by sending a callback as second argument to the UserBadge, and compose the userIdentifier by concatenating the email + companyId. Something like this:

    public function authenticate(Request $request): PassportInterface
    {
        $email = $request->request->get('email');
        $company = $request->request->get('company');
        $userIdentifier = sprintf('%s:$s', $email, $company);
        
        return new Passport(
            new UserBadge($email, function($userIdentifier) {
                [$email, $company] = explode(':', $userIdentifier);
                $user = $this->userRepository->findOneBy(['email' => $email, 'company' => $company]);

                if (!$user) {
                    throw new UserNotFoundException();
                }

                return $user;
            }),
            new PasswordCredentials($password),
        );
    }

I didn't try that code but it should give you a good idea of what to do :)

Cheers!

Thank you, thats so far clear. But what i mean is how to do this with the ?_switch_user .. for that i have to set also the company_id .. is this possible?

In my database, an email can occur more than once. This is made unique in combination via the company_id.

Ohh I get it now. Symfony, internally uses the UserProvider to load the impersonated user object, it calls the loadUserByIdentifier(), so, what you can do is create a custom UserProvider implementing that method, and the $userIdentifier argument will be (as I mentioned above) a combination of your email + companyId. Does it makes sense?
You can check this class if you want to get deeper on how your users are loaded Symfony\Component\Security\Http\Firewall\SwitchUserListener

Hey Abraham,

Here are the docs to configure in-memory users, however it's not recommended for production
https://symfony.com/doc/current/security/user_providers.html#memory-user-provider

Cheers!

Reading some of the items that were already posted in a little more depth, I am using access control.

Hey @Mathew!

Welcome to the comments - I hope we can help :).

Are you able to repeat this locally? If so, turn intercept_redirects to true: https://github.com/symfony/recipes/blob/2d1ba2cf32556d9c01ff7bd05bb02ec9bfb44e5c/symfony/web-profiler-bundle/5.3/config/packages/web_profiler.yaml#L4

This will "stop" redirects. Basically, each time it is about to redirect you, you will instead see a page saying "you're about to be redirected" with a link to the redirect. The reason this is useful is that this page will have a web debug toolbar at the bottom. On that, you'll be able to see if you're still logged in and who you are logged in as. I'm particularly interested in exactly when you are logged out. For example, here is a potential flow that you could confirm or tell me which part is wrong:

A) You add _switch_user=username
B) This is "read" then you are redirected back to the same URL but without the _switch_user=username (because, now, in theory, it has been processed). At this moment, you ARE logged in as the impersonated user.
C) You click a link. You are suddenly redirected to /logout. On this page's web debug toolbar, you can see that you are NOT logged out.

Pay VERY careful attention to where you are or aren't redirected and who you are logged in as in each step. What flow exactly are you seeing? And, when you finally identify the page (well, it will be a redirect to /login probably) where you are mysteriously not logged in anymore, if you click into the profiler, do you see any interesting logs for this page?

Overall, my initial instinct is that you're losing authentication because it appears that your user is "changing". I can go into more detail about that... once if confirm that it is or isn't the problem. A super fast way to check if this is the issue is to:

1) Add EquatableInterface to your User clas
2) In the isEqualTo method (which the interface will force you to have), simply return true.

If the problem goes away, then we've nailed down the cause and we can then debug (pretty easily) why this is happening and a proper solution (the above is NOT a proper solution).,

Lemme know!

Cheers!

Thank you so much for your quick reply!
I have turned on the intercept redirects (which is very helpful) and tried the impersonate process again.. So far, what is happening.
I receive the redirect notice for the following.
- Clicking login (Anon)
- Redirected to Microsoft for credentials (which never displays due to remember me (Anon)
- Redirected to our app's main dashboard (AdminUser)
- Redirected to the admin dashboard once it realizes what roles I have (AdminUser
- From there I click on a link in an impersonation GUI (AdminUser)
- Redirected to the standard non admin dashboard (BasicUser)
- Click on any link or refresh, instantly sent to the login screen with no redirect notice (Anon)

I then tried your second recommendation or implementing EquatableInterface and adding the required isEqualTo method which returns true.

IT WORKED!

I very much appreciate the work that you and your team do. While it may be my first time in the conversation tab, I use your lessons quite a bit. Your lessons are excellent. I wish I had more time to watch them all!

Hey @Mathew!

Woohoo! I'm glad we figured it out! Ok, but before you celebrate TOO much, we should get that isEqualTo() method into a condition where it works AND is "secure". Quick explanation:

A) At the end of each request, the User object is serialized into the session. If you have a _serialize() method or implement SerializableInterface, then those methods will be called to do this. Otherwise, iirc, every property is serialized.

B) At the start of the next request, that User object is deserialized from the session.

C) THEN, the security system queries (assuming your User class is an entity - on a technical level, refreshUser() is called on your user provider) for a "fresh" user. It basically looks at the "id" of your deserialized User object and uses it to fetch a fresh one from the database.

Now, here is where things get interesting. You now have 2 User objects floating around: the deserialized one and the fresh one from the database. At this point, Symfony "compares" these to see if they are "different". And if they ARE different, you are logged out. This is what was happening to you. Why does Symfony compare the objects? It's trying to see if some sensitive data has changed in the database since the user logged in. Here is the most concrete example: suppose a bad user logs in as me on some browser. I find out, log in, and change my password. At this point, our system needs to be smart enough to deauthenticate the "bad user". This "user comparison" process does that.

Normally, to compare the User objects, Symfony uses a built-in algorithm: https://github.com/symfony/symfony/blob/ed9f973de5ed3c950cc0769557919f6ad7a60210/src/Symfony/Component/Security/Core/Authentication/Token/AbstractToken.php#L292-L331 (the logic for this has moved in 6.0, but is still the same).

You can see that it compares several properties on the deserialized User with the fresh User, including password, roles and user identifier. For some reason, once you switched users (and so, the "switched" user would be the one that is now deserialized), this check began to fail. By implementing EquatableInterface, you "took over" and fixed this.

This is a long way of saying that you have 2 options:

A) Figure out why the original logic was failing and fix it. Maybe you are not serializing the roles property so it's missing when you do the comparison? It's a bit weird that you have this problem when switching... but not under normal situations.

B) Keep isEqualTo() but implement your own checks. Ask yourself this about each property on User: if this value changes, should the user be deauthenticated on all other browsers? If yes, then add that check.

Cheers!

I THINK im picking up what you're putting down.. I wrote this up, let me know if this is what you were describing.
I am assuming that you meant to check the userInterface brought in to the isEqualTo method against the user object itself?

public function isEqualTo(UserInterface $user)
    {
        $userObjectHasRole = false;
        $userInterfaceHasRole = false;
        if ($this->hasRole('ROLE_USER'))
            $userObjectHasRole = true;
        $roles = $user->getRoles();
        foreach ($roles as $role) {
            if ($role == 'ROLE_USER')
                $userInterfaceHasRole = true;
        }

        $userInterfaceActive = false;
        $userObjectActive = false;

        if ($user->getStatus())
            $userInterfaceActive = true;
        if ($this->getStatus())
            $userObjectActive = true;

        if ($userObjectHasRole and $userInterfaceHasRole and $userObjectActive and $userInterfaceActive)
            return true;
        else
            return false;
    }

Hey @Mathew!

Apologies for the slow reply! Yes, this is exactly what I had in mind. I would add just a few notes:

A) You could probably simplify by "exiting earlier" instead of storing things in variables. For example:

if ($this->hasRole('ROLE_USER') && !$user->hasRole('ROLE_USER') {
    return false;
}

if ($this->getStatus() != $user->getStatus()) {
    return false;
}

return true;

B) I would also add checks to compare the password of the user... and maybe also the email. You have to ask yourself (for example): is it feasible that the user would ever need to change their email to "regain" for a security reason and want all other browsers currently logged in to be deauthenticated? I think for "password", this is definitely a yes. For email, I'm less sure, but by default, the email address is a field that is normally "compared" in the core algorithm.

Cheers!

Hey Ruslan

That's a good question and it's not actually documented. The anwers relies on a UserProvider. What you need to do is to add a custom user provider for your application, and implement the loadUserByIdentifier() method, that method should be able to find users by email or by id (or whatever other field you may use to identify a user).

Cheers!

Do you mean UserInterface::getUserIdentifier() ? (I fond it in S5.4)

Thank you.

By looking further into it, I think what I'm looking for is not to "prevent" impersonation from happening or "skip" it, because that happens at the moment of switching, whereas I'm looking for something that happens at every request. It's more like: when the session is loaded, I want to somehow retrieve the original user and replace it into the current user... something like that

Hey Matteo S. !

Hmm. This is really interesting... and it's not a problem I've ever thought of before. And once again, it comes back to the "token" object. We know that after we switch users, our token is a SwitchUserToken. And we also know that we can get the original token by saying $token->getOriginalToken().

Using these two things, I think you could trick the system. You would do it by:

A) Register a listener to the RequestEvent (the one that happens early in Symfony). Use a priority of 7 - you can see an example of priorities here: https://symfony.com/doc/current/event_dispatcher.html#creating-an-event-subscriber - the reason I'm using 7 is that the security system is initialized with a listener at priority 8... and we want our listener called right after that.

B) In this listener, inject the Security service and use $this->security->getToken() to get the token object. If this is NOT an instance of SwitchUserToken, just return and do nothing. Or, if the URL does NOT start with /admin, return and do nothing (so, do nothing if the current URL is one where you want the normal switch user behavior to happen).

C) If it IS an instance of SwitchUserToken, then get the token and call $originalToken = $token->getOriginalToken(). store the SwitchUserToken on some property on your subscriber for later - e.g. $this->switchUserToken = $token;

D) Now we are going to take that $originalToken and tell Symfony that we are authenticated using it. Do that by injecting the TokenStorageInterface service, and then call $this->tokenStorage->setToken($originalToken).

E) And... you're done! You should now be logged in as whatever the original user & token was. But, before the request finishes, you need to "restore" the SwitchUserToken, otherwise you'll "lose" the impersonation permanently. To do that, use the same class you created in step (A) and make it listen to ResponseEvent with a priority of 1 (so that you are called before ContextListener, which has a priority of 0). Very simply, if ($this->switchUserToken) then $this->tokenStorage->setToken($this->switchUserToken).

The tk;dr is that you "change" the token to the original right after security starts and change it BACK to the "switch user" token right before security finishes. I can't think of any problems this would cause... it's kind of a cool idea ;).

Let me know how it goes!

Cheers!

So I'm trying this, but I think I've run into a problem. When my listener handles the RequestEvent, and the requested url is an /admin one, it seems that an AccessDeniedException has already been thrown, so apparently it's too late to switch tokens. This is the output of dd($event->getRequest()->attributes) inside my listener:

Symfony\Component\HttpFoundation\ParameterBag {#759 ▼
#parameters: array:4 [▼
"_controller" => "error_controller"
"exception" => Symfony\Component\HttpKernel\Exception\AccessDeniedHttpException {#579 ▶}
"logger" => Symfony\Bridge\Monolog\Logger {#49 …6}
"_stopwatch_token" => "b8c8c0"
]
}
I'm using a priority of 7 for my listener as you said.

Hey Matteo S.!

Ah, darn. I bet I know the issue: part of the Firewall listener (the one that we are trying to execute right *after*) is the enforcement of access_control. So the Firewall listener initializes security (yay!) but then immediately uses the current user to enforce access_control (boo!).

If i'm right, the simplest solution would be to stop using access_control, which may be no big deal... or a huge bummer. If you NEED access_control, then... hmm. Here is another solution that *may* work. In the listener that handles RequestEvent, you're going to convert this into an event subscriber AND a security authenticator. The ResponseEvent logic will stay the same, but the RequestEvent logic get worked into the custom authenticator methods. We're basically going to do the RequestEvent logic but from inside of the authenticator methods, which should allow it to run during the security initialization but after access_control. In supports(), you would check to see if $this->security->getToken() is the SwitchUserToken. If it is, return true. In authenticate(), you would return a SelfValidatingPassport() containing the original user. And you would set the original SwitchUserToken on a property: the same "flow" as before. Then, in the ResponseEvent listener, you would replace the token at the end of the request lke normal.

I'm still making some assumptions here (I'm assuming the logic that loads the SwitchToken from the session and puts that into the security system occurs before your authenticators are called)... so it may not work. Also, this will make it look like your user is being authenticated on every request. What that means in practical terms is simply that events like LoginSuccessEvent will trigger on every request. So if you're relying on this to run code after a user *really* logs in, that'll mess things up. As a work around, you could do everything I said above about the authenticator except that you (A) return false ALWAYS in supports and (B) right before that return statement, you do all the logic of setting the token into the token storage. Basically, you "abuse" the authenticator system: you take advantage of the fact that supports() will be called at the correct time, and then do all your logic there, even though that's not what it's meant for ;).

tl;dr the access_control muddies things a lot. Doing this may still be possible, but it might not (depends on if my assumptions are correct).

Let me know if you get it working!

Cheers!

EDIT: BOGUS COMMENT my bad (I'll leave this to avoid causing confusion if you have aready received a notification of it)

[NOT TRUE:] I have tried the "Stop using access_control" approach. I control access with /** @IsGranted */ annotations instead. Now the flow goes as expected, my listener with priority 7 gets called when I go to /admin too, I can dd() stuff as expected, but even though I switch the token with $this->tokenStorage->setToken($token->getOriginalToken()), I get "access denied" regardless (that's because I wasn't properly checking for the controller being called).

Wooo! I was reading your comment in my inbox thinking "darn, I really thought that would work!". Haha, really happy it did - a nice system!

Thank you soooooooooooo much!! I'll try and let you know. You are the author and voice of the tutorials, right? I ask because I'm reading your replies with your voice in my head and if it's not you I need to stop doing that - lol.

Hey PhpFan,

> I'm reading your replies with your voice in my head and if it's not you I need to stop doing that - lol.

Hahaha, that's funny! :D And yes, you're right! Ryan is the author and the voice of this tutorial ;)

Cheers!

Hey Matteo S.!

Another good question! The answer goes back to the "security token" thing - a topic I don't talk about much in this tutorial because it's rarely useful (but in a few cases, it's very useful). After switching, your "security token" is an instance of SwitchUserToken: https://github.com/symfony/.... You can access this in Twig via app.token. So, app.token.originalToken will give you the "original" token object (probably an instance of UsernamePasswordToken... but it doesn't really matter, since most tokens have all the same methods except for a few special things like SwitchUserToken). To get the original user, it would be app.token.originalToken.user.

I hope that helps :).

Cheers!

Hey Matteo S.!

Effectively nothing. I don't know why both exist. On a technical level:

A) IS_IMPERSONATOR looks for your security "token" to be an instance of SwitchUserToken, which is the token that switch_user gives you.
B) ROLE_PREVIOUS_ADMIN obviously looks for that role... and that extra role is added always when you use the switch_user system.

I had never really thought about it before, but those are two different ways to check for the exact same thing. ROLE_PREVIOUS_ADMIN predates the other... so we may have added IS_IMPERSONATOR to be more clear, but never removed the other way.

Cheers!

Thank you!!! Now with what you said I just grepped (could have done it before actually) and found this:
symfony/security-core/Authorization/Voter/RoleVoter.php: trigger_deprecation('symfony/security-core', '5.1', 'The ROLE_PREVIOUS_ADMIN role is deprecated and will be removed in version 6.0, use the IS_IMPERSONATOR attribute instead.');

Ah, I didn't even realize that! Thanks for the tip!