Where to hook in switching of user identity

[Christopher Bongaarts]

Thanks for sending this; it's great to share alternative approaches...

On 6/24/2016 11:45 AM, Eric Goodman wrote:
> Why in a SAML proxy (beyond "because we have one")?
>
> * I see impersonation as something that's more an SP function than an IdP function, so I like NOT having the impersonation implemented in the IdP. (In fact, most of the reasons we use proxies are to enhance the SPs more than the IdPs). Putting the "impersonation" capability in a proxy also allows us to externalize the implementation, making it easier to leverage by multiple SPs. (I don't think this is really a differentiator in your use case.)

I agree with characterizing impersonation as an SP function.  We 
implemented it on the IdP side (originally in our SSO system that 
preceded Shib) as aid to developers modifying existing applications 
(without impersonability) to use SSO.

> * As a University system, we have multiple (10+) IdPs authenticating users who might need to do impersonation, so externalizing the impersonation reduces the number of IdPs that need to implement (or be convinced to implement) the functionality.

In our case, we have a single IdP for our system, so it's not so bad to 
switch between "the test IdP" and "the spoofing IdP".

> * Externalizing the impersonation function allows SPs to control impersonation is allowed by their selection of IdP. If they trust the actual (shibboleth) IdPs at the campuses, they won't get impersonated accounts. If they trust the "impersonation-enabled" proxy that's the only time impersonation is allowed; (the SAML proxy federates authentication to those same IdPs, so the accounts used by the users don't change).

This is similar to our choice of test vs. spoofing IdP, but ours 
obviously doesn't work as well in a multi-IdP scenario.

> Our impersonation use case so far is for support of test environments; allowing users to act as different functional users (log in as Joe Employee or Jane Student) and not to allow use of multiple "production personas", which may make our use case a little different from yours.
Ours too was intended for testing by developers and QA people against SP 
instances configured specifically for spoofing.  (There's also an access 
control process to limit the population of authorized spoofers.)

We do have a "production" spoofing IdP as well, which is used by a 
single (low-profile but high, core business value) application to 
provide a particular helpdesk subgroup the ability to "see what the user 
sees".

Our most recent major overhaul of enterprise systems (last April) built 
in a "sign in as" function into their application, which eliminated one 
of the largest users of our spoofing IdP.

-- 
%%  Christopher A. Bongaarts   %%  cab at umn.edu          %%
%%  OIT - Identity Management  %%  http://umn.edu/~cab  %%
%%  University of Minnesota    %%  +1 (612) 625-1809    %%