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

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&gt; > To: "Bill Burke" <bburke(a)redhat.com&gt; > 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

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&gt; 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&gt; >>> To: "Bill Burke" <bburke(a)redhat.com&gt; >>> 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

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

From: "Bill Burke" <bburke(a)redhat.com&gt; To: keycloak-user(a)lists.jboss.org Sent: Thursday, 9 April, 2015 2:38:01 PM Subject: Re: [keycloak-user] Impersonate User I think you should ask the users what they want instead of assuming that only impersonating per application is the way to go. There's certainly a lot of different features we could implement around this, but unfortunately there's only so much time to do them.

On 4/9/2015 6:43 AM, Stian Thorgersen wrote: > 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 > -- 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

On 4/9/2015 8:54 AM, Stian Thorgersen wrote: > > ----- Original Message ----- >> From: "Bill Burke" <bburke(a)redhat.com&gt; >> To: keycloak-user(a)lists.jboss.org >> Sent: Thursday, 9 April, 2015 2:38:01 PM >> Subject: Re: [keycloak-user] Impersonate User >> >> I think you should ask the users what they want instead of assuming that >> only impersonating per application is the way to go. There's certainly >> a lot of different features we could implement around this, but >> unfortunately there's only so much time to do them. > I'm not assuming anything I'm just giving my opinion. Besides, we should not always just do exactly what users asks for, we should rather make sure we understand their requirements and come up with good solutions that works for Keycloak and them. > > I'm sure there's situations where a SSO level impersonation would be more convinient. However, a token swap service like I suggested would be much simpler to implement and a lot less risky as well. We should add a token swap service in either case to allow for example downgrading tokens for chained services. > An STS approach would work great for REST services and non-web access, but, what about web apps? Specifically the case where an admin or IT support staff or developer wants to debug a problem a user is having. They impersonate the user so that they can see exactly what is going wrong.

From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt;, "Stian Thorgersen" <stian(a)redhat.com&gt; Cc: keycloak-user(a)lists.jboss.org Sent: Thursday, 9 April, 2015 4:49:45 PM Subject: Re: [keycloak-user] Impersonate User Yeah, I am not sure if token swap service is sufficient.. IMO the admin might want to see (or edit) the account management on behalf of particular user. But our account mgmt is secured by SSO cookie, not token. For web applications, the swapping of token would still require the support on adapters. Basically if admin wants to impersonate as some user in webapp, we still need to figure backup (or invalidation) of admin HttpSession, so the web UI of impersonated session really looks like UI of user and is not polished with some previous state from admin session. The same would need to be solved for JS apps, but here it may be even more tricky... In shortcut, if we want to have something more usable and give to admin the same experience like the impersonated user (including UI experience), we may need to do impersonation at SSO level. And do impersonation as logout of admin session and then SSO re-login of impersonated user. Marek On 9.4.2015 15:07, Bill Burke wrote: > > On 4/9/2015 8:54 AM, Stian Thorgersen wrote: >> >> ----- Original Message ----- >>> From: "Bill Burke" <bburke(a)redhat.com&gt; >>> To: keycloak-user(a)lists.jboss.org >>> Sent: Thursday, 9 April, 2015 2:38:01 PM >>> Subject: Re: [keycloak-user] Impersonate User >>> >>> I think you should ask the users what they want instead of assuming that >>> only impersonating per application is the way to go. There's certainly >>> a lot of different features we could implement around this, but >>> unfortunately there's only so much time to do them. >> I'm not assuming anything I'm just giving my opinion. Besides, we should >> not always just do exactly what users asks for, we should rather make >> sure we understand their requirements and come up with good solutions >> that works for Keycloak and them. >> >> I'm sure there's situations where a SSO level impersonation would be more >> convinient. However, a token swap service like I suggested would be much >> simpler to implement and a lot less risky as well. We should add a token >> swap service in either case to allow for example downgrading tokens for >> chained services. >> > An STS approach would work great for REST services and non-web access, > but, what about web apps? Specifically the case where an admin or IT > support staff or developer wants to debug a problem a user is having. > They impersonate the user so that they can see exactly what is going wrong. > > >

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 > <mailto:prabhalar@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 > <mailto:bburke@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 > <mailto:srossillo@smartling.com>> > >>> To: "Bill Burke" <bburke(a)redhat.com <mailto:bburke@redhat.com>> > >>> Cc: keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@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 <mailto:bburke@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 > <mailto:keycloak-user@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 > <mailto:keycloak-user@lists.jboss.org> > >>> https://lists.jboss.org/mailman/listinfo/keycloak-user > >>> > >>> > >>> _______________________________________________ > >>> keycloak-user mailing list > >>> keycloak-user(a)lists.jboss.org > <mailto:keycloak-user@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 > <mailto:keycloak-user@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

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 <mailto:bburke@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 <mailto:keycloak-user@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 <mailto:keycloak-user@lists.jboss.org> https://lists.jboss.org/mailman/listinfo/keycloak-user