spring security (3.0.x) and user impersonation

Question

In my web application, there are times when an authenticated admin might want to impersonate another valid user of a system without having to know that user's password.

How can I use Spring Security to give admin users the ability to impersonate normal (non-admin) users of the system?

The Spring Security documentation is silent on this and I can't find anything anywhere. Surely someone must have solved this.

Thanks!

Salutation

I was reading the docs the other day...didn't they talk about RunAs? Check out the docs and see if that is relevant to you – Nicki

Answer 1

It's in the Spring Security 3 and Spring Security 4 docs aptly named, "Run-As Authentication Replacement."

The AbstractSecurityInterceptor is able to temporarily replace the Authentication object in the SecurityContext and SecurityContextHolder during the secure object callback phase.

Pontus

Answer 2

I believe the recommended way to do this in Spring Security is with the Domain Access Control lists, see GrantedAuthoritySid @

http://static.springsource.org/spring-security/site/docs/3.1.x/reference/domain-acls.html

However, impersonating another user is more than just having a "delegate identity", you should also consider the implications on logging:

• Do you want your logging to appear as Original User or Impersonated User (or both?)
• Do you want the "impersonation" to show only what the impersonated user sees, or the superset of permissions of the Original User and Impersonated User?

Yet another possibility is to create a "log in as" feature, which essentially changes the principal identity of the current session - or starts a new session with the impersonated identity.

In all of the above, you may inadvertantly open up a security issue - so I think this is why impersonate-style features are not that common place. Rather, designs trend towards Role Based Access Control (RBAC) or Attribute Based Access Control (ABAC). Using RBAC / ABAC, you could create a delegate style feature where you create delegate attributes/roles - and in the special cases where you need to show the source/target of the delegation (e.g. for audit logs), you handle those as corner cases.

Minuet

Nice answer. I would guess he wants to do the "log in as" feature. – Visible

You could also register other SpEL functions so you can say something like hasRole('X') && !isImpersonating() to prevent admin users who are impersonating others from seeing sensitive data. – Comminute

Answer 3

If you want an admin user to be able to impersonate another user (eg for QA/Testing purposes), have a look at the SwitchUserFilter

A decent example of the XML config you need is provided here

Mandate