[keycloak-user] Impersonate User

Thu Apr 9 08:26:43 EDT 2015


----- Original Message -----
> From: "Stan Silvert" <ssilvert at redhat.com>
> To: keycloak-user at lists.jboss.org
> Sent: Thursday, 9 April, 2015 2:15:17 PM
> Subject: Re: [keycloak-user] Impersonate User
> 
> 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.

I totally agree - we can make life easier for app developers by providing a token swap service like I suggested though ;)

> 
> 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 >
> 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