This message was deleted.
# general
m
This message was deleted.
👍 1
m
Hey 🙂 Are you able to share what the specific use case would be for the impersonation? I think this can be solved on the AuthZ level.
a
thanks Vincent. the main service we provide to our users is a members area where they can purchase both individual video packages and video subscriptions. sometimes a user sends a support request because they don't seem to have access to a video that they should, or they have some kind of trouble with their subscription. we have an admin app that enables the admin to view all a user's purchases and subscriptions in the admin dashboard, and that is often adequate for figuring out the problem. but sometimes it's not and we use impersonation (we call it masquerading) to log into the user's account as if we're that user, to see the situation as they see it. this gives us a lot more insight into what exactly they're seeing and we can also use Chrome DevTools to inspect the network traffic, console logs, etc, in order to troubleshoot the problem. is that enough info or do you want to know more?
a
@magnificent-energy-493 many official instances of similar use cases, for example: https://support.google.com/admanager/answer/1241070?hl=en Let me know if Matt's explanation makes sense
s
We think this should be solved rather on a permission level, so the way you do permission checks instead of faking sessions. In the impersonated case, all permissions would be checked for the impersonated user instead of the admin user. So the subject of the permission check can be changed.
a
thanks @steep-lamp-91158. i'm having some trouble imagining how this would operate though. it seems like in order to get our members area to work as if it's the impersonated user, we'd have to pass that userId along with every API request so that the db queries could use that userId for their lookups. or perhaps initiate a session of some sort by sending an API request that will set the userId for all subsequent requests in that session in order to not have to update all of the API payloads. or maybe there's a way to set the userId in the Ory token and the API code can read the userId from the token? how would you see this being done?
a
@steep-lamp-91158 Curious what you think of KeyCloak's impersonation approach: https://blog.devops.dev/user-impersonation-with-keycloak-3397f3451b4
m
It seems Keycloak is using OAuth2 flows for this. I think that this is a good use case for Oauth2, but it comes attached with a lot of complexity and overhead. You could use Ory Hydra to replicate this behaviour. I think using Ory Permissions would be much more manageable and less hacky. That being said I would also be interested what Patrik thinks of it as I am also not super clear how to do it with Ory Permissions 😄 (Its pretty late here in Germany so we will most likely not get an answer ’till Monday)
1
a
ok cool. looking forward to getting his insights.
a
Might be useful to many to put the Ory permissions method in that github thread 🙂
s
Citing from your link:
In direct naked impersonation, a client can impersonate any user in the realm without exchanging subject tokens.
> It is very risky to enable direct naked impersonation for a client. If the client’s credentials are ever stolen, that client can impersonate any user in the system.
which is why they use the oauth2 token exchange for that reason. My proposal is to authenticate admins the same way as any other user using identities (Kratos), and then allowing admins (by checking the appropriate permissions) to switch the subject they act as. You typically have all kinds of permission checks all around your applications, and there you can either user the user ID from the current session (standard way), or look up e.g. in an impersonation mapping table which other subject to use instead (impersonation). This is still a bit generic, but I hope the gist of it makes sense. I'd be very happy to write up an impersonation docs page/guide with your feedback as well.
❤️ 2
🙌 2
a
"I'd be very happy to write up an impersonation docs page/guide with your feedback as well." -> that would be awesome @steep-lamp-91158 we can surely give feedback for it.
a
thanks for the response and explanations @steep-lamp-91158. yes, i'd very much appreciate a guide and would also be happy to give feedback on it.
1
s
Is there any initial feedback right now?
a
@steep-lamp-91158 Well a little bit like the KeyCloak doc that shows the process - or how it would be different from that doc, as @magnificent-energy-493 was explaining above (how it would be simpler & different using Kratos). I think Matt will add some implementation specifics of how he's doing impersionation now (which only works very gracefully using a browser that doesn't save cookies anyway like incognito).
a
@steep-lamp-91158 perhaps i misread the intent of your earlier response. are you asking for feedback from us which will then be used to write up a guide? i read it as you would write up a guide and then get feedback from us.
assuming the former, the only feedback i have right now is more questions. i'm not getting a clear idea of how your recommendation would work in terms of a working implementation. the "impersonation mapping table" concept confuses me. i don't think i know what that means.
what makes sense to me is something like the ideas i gave in this earlier comment: https://ory-community.slack.com/archives/C010F7Z4XM1/p1675446927824499?thread_ts=1675324719.017069&cid=C010F7Z4XM1 the last idea i gave there is one that i can conceptualize easily: "maybe there's a way to set the userId in the Ory token and the API code can read the userId from the token?". in that model, our app basically works just as it normally would, except the userId used for the db lookups is retrieved from the impersonation userId instead of the auth userId.
also, sorry, i accidentally sent the above reply to the main channel. i'm not used to using Slack. and i couldn't undo the action.
but perhaps if you can expain the mapping table a little more, i might understand better.
a
Apparently it is doable in SuperTokens, as one of their devs said:
Thoughts on the above @steep-lamp-91158 @magnificent-energy-493?
m
This implementation by SuperToken still has this problem @adventurous-battery-51816
In direct naked impersonation, a client can impersonate any user in the realm without exchanging subject tokens.
> It is very risky to enable direct naked impersonation for a client. If the client’s credentials are ever stolen, that client can impersonate any user in the system.
It is possible to do this using Ory, but not what we would recommend. I think if you already have an idea how that guide would be most helpful to you and you would create an issue in github.com/ory/docs or github.com/ory/keto , that woudl help Patrik a lot to keep on top of it, as there are many different things he is looking into in a given day. @adorable-scooter-1570 no worries about the Slackpost 🙂 , thanks for sharing more information! If you could compile in on GitHub that woudl be most helpful, as our Slack free plans eats messages after a few weeks. Let me know if I can help.
a
ok i'll do that as soon as i can @magnificent-energy-493.
a
@steep-lamp-91158 said:
You typically have all kinds of permission checks all around your applications, and there you can either user the user ID from the current session (standard way), or look up e.g. in an impersonation mapping table which other subject to use instead (impersonation). This is still a bit generic, but I hope the gist of it makes sense. I'd be very happy to write up an impersonation docs page/guide with your feedback as well.
->>>
what's an impersonation mapping table and where does it exist? What are its attributes? just trying to grok this a bit better before we work on the ory docs angle - we need to get started implementing ASAP. 🙂
Sorry, didn't realize Matt asked it twice, can disregard that
May I ask if you still consider it a security issue if a separate admin app is the only piece with access to impersonate? None of the users use that app to login and it will be protected by long passwords and Ory's 2FA. Only the admin app would get impersonation permissions.