[keycloak-user] Impersonate User

Thu Apr 9 08:38:01 EDT 2015

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 at redhat.com>
>> To: "Scott Rossillo" <srossillo at smartling.com>, "Raghu Prabhala" <prabhalar at yahoo.com>
>> Cc: keycloak-user at 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 at 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 at 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 at smartling.com >
>>>>> To: "Bill Burke" < bburke at redhat.com >
>>>>> Cc: keycloak-user at 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 at 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 at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> keycloak-user mailing list
>>>>> keycloak-user at 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 at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>>
>> _______________________________________________
>> keycloak-user mailing list keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>>
>>
>> _______________________________________________
>> keycloak-user mailing list
>> keycloak-user at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>
> _______________________________________________
> keycloak-user mailing list
> keycloak-user at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/keycloak-user
>

-- 
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com