Subject: Re: [OAUTH-WG] user impersonation protocol?

From: Justin Richer <[email-masked]>
Date: Sun, 15 Feb 2015 23:34:28 -0500

For this case you'd want to be very careful about who was able to do such impersonation, obviously, but it's doable today with custom IdP behavior. You can simply use OpenID Connect and have the IdP issue an id token for the target user instead of the "actual" current user account. 

I would also suggest considering adding a custom claim to the id token to indicate this is taking place. That way you can differentiate where needed, including in logs.

-- Justin

/ Sent from my phone /

-------- Original message --------
From: Bill Burke <[email-masked]> 
Date:02/15/2015  10:55 PM  (GMT-05:00) 
To: oauth <[email-masked]> 
Cc:  
Subject: [OAUTH-WG] user impersonation protocol? 

We have a case where we want to allow a logged in admin user to 
impersonate another user so that they can visit differents browser apps 
as that user (So they can see everything that the user sees through 
their browser).

Anybody know of any protocol work being done here in the OAuth group or 
some other IETF or even Connect effort that would support something like 
this?

Thanks,

Bill

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

_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Bill Mills <[email-masked]>
Date: Mon, 16 Feb 2015 05:37:40 +0000 (UTC)

User impersonation is very very risky.  The legal aspects of it must be considered.  There's a lot of work to do to make it safe/effective.
Issuing a scoped token that allows ready only access can work with the above caveats.  Then properties/componenets have to explicitly support the new scope and do the right thing. 

     On Sunday, February 15, 2015 8:34 PM, Justin Richer <[email-masked]> wrote:

-------- Original message --------

Thanks,

Bill

---

From: Bill Burke <[email-masked]>
Date: Mon, 16 Feb 2015 10:20:18 -0500

Yeah, I know its risky, but that's the requirement.  Was just wondering 
if there was any protocol work being done around it, so that we could 
avoid doing a lot of the legwork to make it safe/effective.  Currently 
for us, we need to do this between two separate IDPs, which is where the 
protocol work comes in...If it was just a single IDP managing 
everything, then it would just be an internal custom IDP feature.

Thanks all.

On 2/16/2015 12:37 AM, Bill Mills wrote:
> User impersonation is very very risky.  The legal aspects of it must be
> considered.  There's a lot of work to do to make it safe/effective.
>
> Issuing a scoped token that allows ready only access can work with the
> above caveats.  Then properties/componenets have to explicitly support
> the new scope and do the right thing.
>
>
> For this case you'd want to be very careful about who was able to do
> such impersonation, obviously, but it's doable today with custom IdP
> behavior. You can simply use OpenID Connect and have the IdP issue an id
> token for the target user instead of the "actual" current user account.
>
> I would also suggest considering adding a custom claim to the id token
> to indicate this is taking place. That way you can differentiate where
> needed, including in logs.
>
> -- Justin
>
> / Sent from my phone /
>
>
> [email-masked] <mailto:[email-masked]>