3

I'm using Spring Security to provide authentication and authorization to my webapp.

I use the standard method UserDetails loadUserByUsername(String username) throws UsernameNotFoundException; to login with a DaoAuthenticationProvider.

Once successfully logged in, I can access the user's authorities in two different ways:

1# SecurityContextHolder.getContext().getAuthentication().getAuthorities()

2# ((UserDetails) SecurityContextHolder.getContext().getAuthentication().getPrincipal()).getAuthorities()

They are supposed to be the same, as the Authentication instance authority list is constructed from the UserDetails' user.getAuthorities(), but they are in fact 2 different Collection instances. The principal's one is an UnmodifiableSet, the one in the Authentication instance is an UnmodifiableRandomAccessList. 2 different Collection instances that contain the same list of authority.

This struck me when trying to find a solution to dynamically add an authority to the currently authenticated Principal. It's not a good thing and the security layer should not allow me to do so, but still that's what I need.

A solution I found acceptable was to programmatically login with the currently authenticated user with new UsernamePasswordAuthenticationToken(authentication.getPrincipal(), authentication.getCredentials(), dbAuthsSet);

authentication being the current authentication instance and dbAuthSet the current list of authorities + the one I need to add.

And this works fine. The only odd thing now is that

1# SecurityContextHolder.getContext().getAuthentication().getAuthorities()

2# ((UserDetails) SecurityContextHolder.getContext().getAuthentication().getPrincipal()).getAuthorities()

don't return the same list of authorities anymore.

If I check authorities against the Authentication's list in my application, I'm good, and this is perfectly justified thing to do. But if I check against the Principal's list, I'm faced with the inconsistency.

What do you think? Is it a problem that should be addressed in Spring's Security 3.2?

Do you find it reasonable to programmatically login with new UsernamePasswordAuthenticationToken() to achieve my goal of giving an additional authority to the currently authenticated user for the session?

Would it be a good case to use Spring's Run-As Authentication Replacement feature? Could anyone share experience on this ?

coolnodje
  • 789
  • 1
  • 7
  • 20
  • 1
    I think that the obvious question is - What are you trying to achieve? What is your use-case? – Pavel Horal Aug 12 '13 at 16:15
  • The business level use-case is for an admin to be able to impersonate a user. My solution is to dynamically give it the necessary authority after it selects the user to impersonate. It's then seen as a user by the system and can perform user's action. – coolnodje Aug 13 '13 at 08:44
  • 1
    Check http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/web/authentication/switchuser/SwitchUserFilter.html – Pavel Horal Aug 13 '13 at 10:59
  • Very good piece of advice, it's barely mentioned in the Spring 3.1 documentation, I'm glad you pointed it to me. Thank you so much! – coolnodje Aug 14 '13 at 07:15

0 Answers0