Where to hook in switching of user identity

Eric Goodman Eric.Goodman at ucop.edu
Fri Jun 24 16:33:39 EDT 2016


>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?

See my response to Walter: there's nothing to stop you from releasing both the "real" subject ID and the "impersonated" one to the SP, so it seems like delivered logging should be fine. The proxy impersonation function might require some custom logging (to indicate "user1 allowed to impersonate user2"), but the "impersonate" function is going to require a custom page (and likely database) anyway, so there's a natural place to add said logging as necessary. 

And I think in both cases that the SP is volunteering to be "spoofed" by pointing at an IdP or SAML Proxy that supports impersonation. Given that, I would think that the more important audit responsibility would be for the application ("is it okay for your users to leverage the impersonation service?") than for the IdP operator -- though I haven't tested this hypothesis with actual auditors. Also, the use case for this function is to replace existing shared test accounts (with shared passwords) that are already being used for testing, so there's a good argument that it's better than the current practice. 

--- Eric




More information about the users mailing list