Where to hook in switching of user identity

[David Langenberg]

So, with all this spoofing stuff, how do you deal with non-repudiation of the spoofed accounts for auditors?  Did you modify the logs/assertion to sufficiently indicate to the SP and/or within the IdP that the particular authN event is being spoofed by a particular identity?

Dave

-- 
David Langenberg
Identity & Access Management Architect

The University of Chicago







On 6/24/16, 12:45 PM, "users on behalf of Eric Goodman" <users-bounces at shibboleth.net on behalf of Eric.Goodman at ucop.edu> wrote:

>>The user ("spoofer") enters their own credentials (username/password), and the identifier of 
>>the user they want to impersonate ("target"), as well as the authentication method they want 
>>to simulate.  The IdP then creates a session with the target user as the principal and the 
>>simulated auth method as the auth type.  Thus, the SP sees the user as having authenticated 
>>as the target user, with the target auth method, and receives attributes for the target user.
>
>We are considering implementing similar functionality, but we're looking at doing it in a SAML Proxy (SSP). Partly the consideration of using the proxy is that we already run such a Proxy in production for other reasons, so have hammer, perceive nail. The idea would be that the proxy would still allow the user to authenticate normally (by handing off actual authentication to the IdP), but then the asserted identity would be modified before delivery to the SP.
>
>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.)
>
>* 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.
>
>* 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). 
>
>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.
>
>I'll also reiterate that this is all discussion at this point, we haven't developed or deployed these capabilities, just investigated the options and diagramed what we might want to do about them.
>
>--- Eric
>-- 
>To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net