Impersonation details - New feature request

[Schwoerer, Brad]

Scott,

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.  The flow I imagined would need to happen is that the user would start at the onbehalfof app where they could request access for a certain application on-behalf of the certain person.  The same app would be where they would authorize other users to act on their behalf as well.  The application would do an initial check and if so authorized, do an idp initiated request with an overload parameter for the desired user.  The idp would authenticate the requestor, do the authorization check a second time and ask for understanding/approval checkbox.  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.

-Bradley




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

>On 10/9/17, 11:10 AM, "dev on behalf of O'Dowd, Josh" <dev-bounces at shibboleth.net on behalf of Josh.O'Dowd at mso.umt.edu> wrote:
>> Is it the ability for an authorized subject to authenticate, where the resulting subject c14n represents an impersonated subject,
>> fully audited, and under strict constraints?
>
>No, because that's much riskier and more expansive than 99% of people would ever need.
>
>What I did was build an interceptor that obtains a list of authorized account names and directs it to re-reresolve the attribute set based on a selected account name *for a single response* to a service.
>
>The identity in the session never changes. It just passes out data for a different identity one request at a time, and you can plug in a function to return the list of authorized identities on a per-anything basis.
>
>-- Scott
>
>
>-- 
>To unsubscribe from this list send an email to dev-unsubscribe at shibboleth.net