Impersonation details - New feature request

[Schwoerer, Brad]

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.



-Bradley






On 10/9/17, 1:46 PM, "dev on behalf of Cantor, Scott" <dev-bounces at shibboleth.net on behalf of cantor.2 at osu.edu> wrote:

>On 10/9/17, 2:39 PM, "dev on behalf of Schwoerer, Brad" <dev-bounces at shibboleth.net on behalf of schwoerb at uww.edu> wrote:
>
>> I was just thinking about doing something similar over the past week, but making it such that the user would authorize based
>> upon application and not for all applications.
>
>Yes, exactly. I think that's the norm, but I think you're overcomplicating the interaction with the IdP, and essentially requiring a totally new binding, which is a much larger amount of work with much more risk of opening a hole. What I built is all you need, your "onbehalfof app" just needs to maintain the database that supplies what I built with the list of accounts to allow. There's no reason to require IdP-initiated anything, they don't need to be coupled at all other than through the data format in your IDM, which is nothing the IdP has to be wedded to.
>
>>  I think a standard secondary attribute about the authenticated user gets sent to the SP, such that the SP can decide how to log
>> the actions in the application.
>
>The resolver should be able to detect when this is happening so a custom attribute could be resolved at that stage to send along. Probably it can be as simple as extending the AttributeResolutionContext with some kind of generic label field that would have values specific to any time the resolver runs, so people running it themselves (e.g. inside an MFA control rule) could slap a label on that and do custom logic.
>
>Point being, this should all be convention in your deployment, nothing we dictate in the product.
>
>-- Scott
>
>
>-- 
>To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net