Howdy,

I'm having an issue and I'm wondering if anyone else is experiencing it. We use SAML to log into our Drupal site. Once I login and I attempt to masquerade (Masquerade is a Drupal module that allows you to login as another user) as another user, the site simply logs me out.

When I login via the typical /user path (NOT /saml_login), Masquerade works as normal.

Any ideas?

Command icon Show commands

Start within a Git clone of the project using the version control instructions.

Or, if you do not have SSH keys set up on git.drupalcode.org:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Nitebreed’s picture

Version: 7.x-2.0-alpha1 » 7.x-3.x-dev
Issue summary: View changes

Having the same issue. Noticed it has to do with the user I was masquerading to didn't have a role that was enabled for local login

odegard’s picture

Can cofirm. Users you want to masquerade to must be specified in "Which users should be allowed to login with local accounts?", or leave blank for all.

Zekvyrin’s picture

This is closely related to #2478499: User 1: Automatic Logout after saving configuration

It's exactly the same code which logs out users not authenticated from simplesaml.

odegard’s picture

Status: Active » Needs review
FileSize
1.33 KB

I've taken a closer look at this and found a solution, see patch.

It is as Zekvyrin points out a problem with simplesamlphp_auth_user_logout - it logges out "too much".

I've not been able to solve the "problem", I've found a way around it. Caveat emptor.

I considered two options:
1) Patch masquerade to set a session variable before invoking user_logout which runs simplesamlphp_auth_user_logout AND patch simplesamlphp_auth to check for this variable.
2) Find another way that only affects simplesamlphp_auth.

This patch incorporates option 2 by checking the backtrace for the two masquerade-functions involved when invoking user_logout.

odegard’s picture

Updated patch. Switched out ddebug_backtrace with debug_backtrace since the first one requires that the user has access to devel and normal users should not.

Berdir’s picture

Title: Unable to masquerade when logging in via SAML? » Unable to masquerade when logging in via SAML
Version: 7.x-3.x-dev » 8.x-3.x-dev
Category: Support request » Bug report
FileSize
580 bytes

Here is an 8.x patch that relies on #2975124: Masquarade Saml compatibility issue and then checks for the session key, much less hackery required but it does need a masquerade patch too per the previous issue.

Berdir’s picture

Also, you will likely also need the patch from #2975184: Masquerading as user not authenticated causes logout to remain logged in.

andypost’s picture

andypost’s picture

Masquerade issue commited

jplana’s picture

I can confirm the patch #6 works for me, with the latest dev branch of the masquerade module.

Thanks @Berdir for the patch and @andypost for the tip!

joelpittet’s picture

Status: Needs review » Reviewed & tested by the community

This is helpful thanks @andypost and @Berdir!

andypost’s picture

Berdir’s picture

There's also a related issue here: #2975184: Masquerading as user not authenticated causes logout, you might need that if you disallow local logins for example. Testing of that would be appreciated so I can commit both. FWIW, this patch should also switch to doing a hasService() && isMasquerading approach to use the API like the new patch over there.

joelpittet’s picture

Rerolled

fengtan’s picture

We faced the same issue in Drupal 7 and were able to fix it by applying this patch from the masquerade module (it has been committed to 7.x-1.x-dev but has not been included in a stable release yet): https://www.drupal.org/project/masquerade/issues/2124113#comment-11760980

devkinetic’s picture

#11 working great!

Kobe Wright made their first commit to this issue’s fork.

Kobe Wright’s picture

Encountered a fatal after a D9 upgrade when trying to masquerade while being logged in using simplesaml because the $account parameter is a User object (not AccountProxy) which doesn't have the setAccount() function.

Created an issue fork with a solution based on the patch in #14, opted to check if the masquerade module is enabled and leaving it up to that module to indicate if the user is masquerading.

Kobe Wright’s picture

Status: Reviewed & tested by the community » Needs review
Elmis Hernandez’s picture

Hello,

I also found this problem and although they say that #14 works, for me it worked only after applying it also in the Subscriber.

Here I leave my change and the difference between #14 and my change.

hfernandes’s picture

#21 worked here.

devkinetic’s picture

Status: Needs review » Reviewed & tested by the community

This looks good to me as well.

kecsot’s picture

Would be nice to implement another solution except hardcoding 'masquerading' session check to simplesamlphp_auth.
Also good idea to Close with won't do.

What do you think?