This message was deleted.
# general
m
This message was deleted.
s
this is not supported in the way you described due to security concerns and best-practices
if you need this for some support requests, we recommend to authenticate the user properly, and then add something like a "impersonate as" field to a request this way, you can still fully trust the authentication, and you can add authorization checks around what user is allowed to impersonate what other user under what conditions
r
@steep-lamp-91158 Thanks for responding. What you mean by "authenticate the user properly"?
s
the user who would get the impersonation session needs to authenticate somehow as well, but using their own credentials only after you know that they actually are who they claim to be, you should allow them to "impersonate" someone when you create a session using the admin API, you run the risk of not properly authenticating the user
r
That all sounds like a Hydra thing, right?
s
depends, but that's something you have to keep in mind when building impersonation and why we don't support it natively
r
@steep-lamp-91158 Can you provide a little more detail?
I understand that creating a session via Kratos' admin API is a security issue, etc. but then how is one supposed to do this?
s
In your app at some point you determine the current user, with Kratos by taking the user ID from the whoami response. There you can add a way to use a different user ID instead:
Copy code
func getCurrentUserID(req *http.Request) (string, err) {
  user, err := getWhoAmI(req)

  if impersonated := req.Headers.Get("Impersonated-User-Id"); impersonated != "" {
    if isAllowedToImpersonate(user, impersonated) {
      return impersonated, nil
    }
  }
  return user.id, nil
}
For reusability, it would obviously be best to do this in a gateway, depending on your setup.
Also, you'd have to have some admin panel that allows to find the user ID and adjusts the client to always send the header. Cookies would obviously also work, or any other way.
this way you always do the right authn & authz checks
r
Oh, I see what you mean. So build some kind of mechanism that adds the header or a cookie, etc.. And then use something like your code at a central place.
We currently use oathkeeper to extract the user ID and pass it on to services. I am wondering if there's a way to do this in OAthkeeper
So we use a mutator right now and the backend is fully agnostic or oblivious to what "authn" is 😄