pomerium: Impersonate doesn't seem to work

Describe the bug

After entering a user email or a group in the impersonate input (user and/or group) and clicking on impersonate, nothing happens: it seems there is a 302 that redirects me to the same /.pomerium url but I’m still logged as myself and not the impersonated user.

Expected behavior

To have my session updated as if I was logged as the user (or the group).

Environment:

  • Pomerium version (retrieve with pomerium --version): v0.0.5
  • Server Operating System/Architecture/Cloud: AKS

Configuration file(s): See #152 a always 😉

Logs:

{"level":"debug","fwd_ip":"10.240.0.66","ip":"10.240.0.52","user_agent":"Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0","referer":"https://app.xxx.com/.pomerium","req_id":"af0966fc-1965-10f6-3905-5994d80923ea","duration":5.587115,"size":0,"status":302,"email":"","group":"","method":"POST","service":"proxy","url":"/.pomerium/impersonate","time":"2019-06-11T15:27:19Z","message":"http-request"}
{"level":"debug","fwd_ip":"10.240.0.66","ip":"10.240.0.52","user_agent":"Mozilla/5.0 (X11; Linux x86_64; rv:67.0) Gecko/20100101 Firefox/67.0","referer":"https://app.xxx.com/.pomerium","req_id":"8bc2ad55-c02b-8991-0aeb-27b85d4b5e26","duration":5.144314,"size":12244,"status":200,"email":"victor.noel@xxx.com","group":"all@xxx.com,infra@xxx.com,support@xxx.com","method":"GET","service":"proxy","url":"/.pomerium","time":"2019-06-11T15:27:19Z","message":"http-request"}

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 18 (6 by maintainers)

Most upvoted comments

@desimone yep, I see no problems with keeping the current behaviour in case rootDomain is not explicitly set (except that it is more complexity to maintain 😉.

@desimone and also, if this could go into v0.1.0, it would neat 😃

Following our discussion offline, I concur with the idea of a user supplied root domain configuration.

Two more points/ideas:

  • I guess it should be used not only for cookies but also for (sub)domain validation (as in #152).
  • If I have as a root domain a.xxx.com, authenticate service url shouldn’t have to be one level under the root domain, it could perfectly be auth.b.a.xxx.com, right?

Also, as I told you, I would even go to the point of removing any “smartness” from pomerium so that the only way to know the root domain is to explicitly specified it in the configuration. I don’t think it’s a bad design decision because it both removes any unexpected behaviour and ops rarely changes this setting once it is set.

sorry, I made a mistake with the domain of the cookie after impersonating, it’s fixed in the comment above

another question: can this be related to allow_public_unauthenticated_access: true?

It could in the sense that allow_public_unauthenticated_access skips authentication entirely. No session is loaded, and the route would not be “identity aware”. That would only be for that route, though.

Sorry, wrong question, I thought you had enabled it for the route we were talking about 😃

I think I will try latest dev version of pomerium soon (to also validate everything works as expected for the sign out thing) and see if this issue is really a problem or if it’s related to v0.0.5.

@desimone some things are different in my experience (with v0.0.5):

  • my use case is the complement of the one you show: I am not a member of the authorized group for the protected service and I would like to be included in the group via impersonation in order to access it.
  • when I enter a username and/or a group in the /.pomerium page and click impersonate, the input fields for impersonation are cleared while in your video they are not.
  • once I clicked “impersonate”, if I go to the protected app, I’m still unauthorized.

Another unclear thing is: if I impersonate a user, will I be authorized to access app that are authorized to groups this user is a member of, or will this only give me access to app explicitly authorized to this particular user? I would expect the first 😃