[keycloak-user] Impersonate User

[Marek Posolda]

On 10.4.2015 06:33, Stian Thorgersen wrote:
> True a separate service might be to much work for applications to implement.
>
> How about just having a kc_impersonate query param available in auth endpoint? In that case the adapter logs-out the current session, then redirects to auth endpoint with kc_impersonate=<username>? That way your still impersonating a single app rather than the whole SSO session and you can also have an option on each app to enable/disable impersonation.
If I understand correctly, it means that UserSession on auth-server side 
would be still the session of "admin", but we will need to track which 
ClientSessions of this UserSession were impersonated. So the 
impersonation will be tracked per ClientSession. Is it correct? 
Refreshing token probably won't be a problem, as auth-server will know 
which clientSession was impersonated and will be able to grant 
accessToken for impersonated user.

One thing is, that adapters will need to support some kind of "local" 
logout. As we will need to support logout on application side, but not 
logout of corresponding userSession on auth-server though. So some 
special logic on adapters might be still needed though...

Also it won't address the impersonation of account-management 
application though, as this one is secured by our SSO cookie.

So not sure... I am probably still slightly more inclined to do it per 
SSO;-)

Marek

>
> ----- Original Message -----
>> From: "Marek Posolda" <mposolda at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen" <stian at redhat.com>
>> Cc: keycloak-user at 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 at redhat.com>
>>>>> To: keycloak-user at 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.
>>>
>>>
>>>
>>