Impersonation details - New feature request

[Schwoerer, Brad]

I would agree if the IDP doesn't offer a way to communicate it to the app, or exclude an app on the SPs request.  Like all things, it will take time for the apps to catch up to the functionality, but I think it is necessary moving forward.  This is why I think it is important, as an implementer, to only enable it on an app-by-app basis.  There needs to be a way for an SP to not to want to accept.  Until there are profiles and the such, that is on IDP side to not allow it for a particular app.

-Bradley






On 10/10/17, 9:14 AM, "dev on behalf of Mike Schwartz" <dev-bounces at shibboleth.net on behalf of mike at gluu.org> wrote:

>Shib Devs,
>
>I've always pushed back on the idea of impersonation using SAML or 
>OpenID Connect. Doesn't it undermine the integrity of the system if 
>someone else can login as you?
>
>I think it's possible with a user-initiated UMA claims gathering flow.
>
>- Mike
>
>
>On 2017-10-09 15:21, Cantor, Scott wrote:
>> On 10/9/17, 2:58 PM, "dev on behalf of Schwoerer, Brad"
>> <dev-bounces at shibboleth.net on behalf of schwoerb at uww.edu> wrote:
>> 
>>> I agree that I want to make this simple, I just couldn't think of an 
>>> elegant user flow.  Ideal would be a way to have a user initiate
>>> an impersonated/onbehalfof session without interupting every 
>>> authentication flow for the user to have a chance to choose that
>>> they want to have this session for this app be impersonated.
>> 
>> I think that's a feature. Silently switching is not a good thing IMHO.
>> 
>> -- Scott
>-- 
>To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net