Re: [keycloak-user] Impersonate User

IMO impersonation shouldn't be done at the SSO level, it should be for a specific application and we should just have a endpoint that allows "swapping" a token for an admin user for a token for a different user. To invoke the endpoint you'd have to have a token for an admin user with a special 'impersonate' role. We also need to some way of controlling what roles can be impersonated. That could be done by having a impersonate application where it's possible to set scope. ----- Original Message ----- > From: "Marek Posolda" <mposolda(a)redhat.com&gt; > To: "Scott Rossillo" <srossillo(a)smartling.com&gt;, "Raghu Prabhala" <prabhalar(a)yahoo.com&gt; > Cc: keycloak-user(a)lists.jboss.org > Sent: Thursday, 9 April, 2015 9:23:43 AM > Subject: Re: [keycloak-user] Impersonate User > > This is very similar to how I've implemented impersonation in GateIn portal. > Basically the session wrapped the "admin" session and after logout, the > admin session was restored back. So admin wasn't logged-out, but he was able > to continue with his session in exactly same state like before > impersonation. > > But for the Keycloak, it will be very tricky to support this as Keycloak is > SSO and admin is already logged to some applications before he started > impersonation session. So for support of save/restore the admin session, we > would need to implement the "stack" for the UserSession on auth-server but > also for all the application sessions. This might be possible (but quite > tricky) for servlet adapters, but I am not seeing how to properly support it > for JS adapter... > > In shortcut, it seems that we would really need to logout original admin > session and then login as impersonated user. For audit purpose, we will have > info that session is impersonated, but IMO we will not be able to restore > original admin session back to the state before impersonation. > > Marek > > > On 8.4.2015 16:56, Scott Rossillo wrote: > > > > One thing I've seen done with Spring Security (custom code) is to implement > the impersonation as a "stack." An admin impersonating another user gets > pushed instead of logged out and when the impersonated user is logged out, > the admin is popped and re-becomes the principal. This may be much more > complex with distributed security, but the pseudo code of the token would be > something like: > > public class KeycloakSecurityContext { > boolean isImpersonated; > KeycloakSecurityContext impersonatingContext; > } > > This is obviously only one aspect but could be used by an application to know > if the user is impersonated, and who's doing the impersonating. > > ~ Scott > > > On Wed, Apr 8, 2015 at 10:17 AM, Raghu Prabhala < prabhalar(a)yahoo.com > > wrote: > > > Jumping in with my requirements as Impersonation is a very sensitive issue. > It has to be read only and clearly indicated in both gui and audit engine( > logs). We typically require both the admin and user information populated > for audit purposes which means that the admin should not be logged out. > > Sent from my iPhone > >> On Apr 8, 2015, at 9:55 AM, Bill Burke < bburke(a)redhat.com > wrote: >> >> I worry a bit about how this can be exploited. I think it might need to >> be its own service that >> >> 1. checks and verifies the admin is logged in (via the cookie) >> 2. Re-authenticates the admin manually >> 3. Logouts out the admin and logins him in as impersonated user. >> >> There might be other sensitive areas/features where we might want to >> require manual re-authentication before. >> >> Also, we might also want to add information to the id/access tokens and >> saml assertions for auditing purposes so that clients know that the user >> is being impersonated. >> >> FYI, I know this is a must-have feature in order for Red Hat IT to use us. >> >> >>> On 4/8/2015 12:53 AM, Stian Thorgersen wrote: >>> I would say an admin would need a special role as well as having all the >>> roles of the user the admin wants to impersonate. >>> >>> That's the simple part, second part would be to let an admin login as >>> another user. Maybe that could be done with a query param to the >>> authorization endpoint, for example: >>> >>> /realms/myrealm/protocols/openid-connect/auth?...&kc_impersonate=<username> >>> >>> Would also be good to have a enable/disable option for this feature for a >>> realm. >>> >>> ----- Original Message ----- >>>> From: "Scott Rossillo" < srossillo(a)smartling.com > >>>> To: "Bill Burke" < bburke(a)redhat.com > >>>> Cc: keycloak-user(a)lists.jboss.org >>>> Sent: Wednesday, 8 April, 2015 1:13:19 AM >>>> Subject: Re: [keycloak-user] Impersonate User >>>> >>>> Thanks. >>>> >>>> Out of curiosity, how do you see this being implemented? Would a user who >>>> can >>>> impersonate another have a specific role to allow this? >>>> >>>> I’m thinking a bit about how I may be able to support it before it >>>> becomes a >>>> feature, or if it’s something we would be able to contribute. >>>> >>>> ~ Scott >>>> >>>> >>>> >>>> On Tue, Apr 7, 2015 at 6:06 PM, Bill Burke < bburke(a)redhat.com > wrote: >>>> >>>> >>>> We don't have this feature but it is something that some key customers >>>> want. I would say we would get to it sometime this summer. >>>> >>>>> On 4/7/2015 6:03 PM, Scott Rossillo wrote: >>>>> Hi, >>>>> >>>>> We’re looking for the best way to support having one user, such as an >>>>> admin, have the ability to impersonate another user. I don’t see a >>>>> simple way to do this with Keycloak at the moment. >>>>> >>>>> Would you mind letting me know if this is on the roadmap - I didn’t see >>>>> a JIRA - or if you have any recommendations on implementing such >>>>> behavior. >>>>> >>>>> Thanks, >>>>> Scott >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> keycloak-user mailing list >>>>> keycloak-user(a)lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> -- >>>> Bill Burke >>>> JBoss, a division of Red Hat >>>> http://bill.burkecentral.com >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >>>> >>>> >>>> _______________________________________________ >>>> keycloak-user mailing list >>>> keycloak-user(a)lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/keycloak-user >> >> -- >> Bill Burke >> JBoss, a division of Red Hat >> http://bill.burkecentral.com >> _______________________________________________ >> keycloak-user mailing list >> keycloak-user(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-user > > > > _______________________________________________ > keycloak-user mailing list keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user > > > _______________________________________________ > keycloak-user mailing list > keycloak-user(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/keycloak-user _______________________________________________ keycloak-user mailing list keycloak-user(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-user