Changing Authorities

[dmarner]

I need to provide my users the ability to assume different sets of Authorities on one account, without logging out and back in. The idea is that users have multiple roles avaliable to them, allowing them to fill in for other users. At login a user is assigned a default set of Authorities, but they may choose to switch to choose a different role with a different set of Authorities at any time.

What is the best way to dyamically update the Authorities associated with their Authentication object? I can think of a few ways it might be done... ACLs come to mind as a way it COULD be done, but they are not a perfect match since I am not really trying to manage permissions on a domain object.

[Ben Alex]

There are quite a few ways this could be done.

The optimal way is to get all knowledge of switchable GrantedAuthority[]s handled within your AuthenticationDao. The way the AuthenticationDao "knows" which GrantedAuthority[]s it should add to the returned UserDetails is a matter for you to decide. Some approaches include mutating the username to include a delimiter and then some sort of "loginCategory" identifer, extending SecureContext to include a loginCategory, or accessing some DB table which reports the session's current loginCategory.

Probably SecureContext is the best approach. From 0.9.0 and in CVS currently this is replaced by SecurityContext - but for all intents and purposes it is the same.

If you do not have different usernames to represent each username:loginCategory combination, you'll need to evict the username from the UserCache whenever the principal switches loginCategory. Otherwise the AuthenticationDao will not be re-queried to return the now-applicable GrantedAuthority[]s.

Alternatively, you could forget using the RoleVoter and instead return a custom GrantedAuthority which contains the "roleName" and an "applyIfLoginCategory". Your MyCustomRoleVoter would then consult the SecureContext ThreadLocal to determine which role(s) are active. It could then simply ignore roles not applicable at a given time. The advantage of this is that you are fully populating the Authentication and never need to worry about incorrect cache handling.

[fractal76]

There are quite a few ways this could be done.

Ben, you mention a couple of different ways that changing granted authorities can be done. But I am still not very clear on what is the standard pattern for doing simple runtime changes to roles.

My use case is the following:
An admin can change ROLE of user at runtime through an Admin UI. While the admin is changing user's ROLES (ie his granted authorities), the user is actually logged-in into system. So the users Authentication object is stored in the SecuritySession.

I will actually have my own AuthenticationDao, UserDetail, GrantedAuthorityImpl classes which will allow me to update UserDetail data in the database at will. However updating the data in database is not enough, somehow i need to inform acegi that it needs to reload UserDetails (assume that only GrantedAuthorities change - changing password and other userdetail attributes can be left for another thread )

You suggest clearing out the UserCache. Does this cause the Authentication object stored in current user session to be rebuilt (at least some of it - particularly with new GrantedAuthorities).

So my understanding of the whole process at the moment is:
1. Present some admin ui that allows admin to load a particular user by username.
2. Show list of preset roles.
3. Admin changes roles associated with user.
4. Custom authentication dao persists the new user to grantedauthority association to db.
5. Some code tells UserCache to clear out changed user's cached info - thus causing the current Authentication object in that users session to be rebuilt.
6. The next action of the changed user in that user's current session will be authorized against the new set of GrantedAuthority[]

Is this essentially correct?

Are there any non obvious threading issues to be concerned about? (for example the user whose granted authorities are being changed could be executing some actions at the same exact time as admin is changing them)

[Ben Alex]

Your overview is correct. A related thread is http://forum.springframework.org/viewtopic.php?t=4624

There shouldn't be any threading issues as your eviction from the UserCache is a different object than the Authentication stored in the HttpSession and possibly being accessed.

Removing a UserDetails from the UserCache will cause it to be rebuilt next time the AuthenticationProvider is called (which will be the next time a secure object or authentication is requested).