[keycloak-user] Impersonate User
Stan Silvert
ssilvert at redhat.com
Thu Apr 9 08:15:17 EDT 2015
I've only worked on one application that required impersonation, but we
thought about the problem differently.
It was the corporate travel offering from Sabre. The problem was that
an administrative assistant needed to be able to book travel for one or
more executives. The assistant would not actually impersonate the user,
but the application simply knew who she was allowed to book travel for.
Therefore, impersonation was really more like composite roles that
included a user name (or a wildcard for "any user"). It was up to the
application to know what to do with the roles. It would present a
drop-down to select which user you were working on behalf of.
This way, you never require more than one login or logout. You are just
pushing all the complexity onto the application. But maybe that's
where it belongs.
On 4/9/2015 3:23 AM, Marek Posolda wrote:
> 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
>> <mailto: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
>> <mailto: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
>> <mailto:srossillo at smartling.com>>
>> >>> To: "Bill Burke" <bburke at redhat.com <mailto:bburke at redhat.com>>
>> >>> Cc: keycloak-user at lists.jboss.org
>> <mailto: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 <mailto: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
>> <mailto: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
>> <mailto:keycloak-user at lists.jboss.org>
>> >>> https://lists.jboss.org/mailman/listinfo/keycloak-user
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> keycloak-user mailing list
>> >>> keycloak-user at lists.jboss.org
>> <mailto: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
>> <mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/keycloak-user/attachments/20150409/3d7bb8c1/attachment.html
More information about the keycloak-user
mailing list