* As mentioned by Bear Bibeault, if you are trying to have a distinct HTTPSession for each browser window, it is going to be a complicated and messy implementation if at all possible, and I would avoid it at all costs.
* I assume you have a 'user' object in your session that you populate when a user logs in.
I would not recommend replacing the session info with a different user's details altogether. Even if the super user wants to do things as a regular user, there should be a record of the fact that it was done actually by the superUser acting as the regular user. If your session has a 'user' object to identify the current user, you could add a 'loggedInAs' to identify the user being simulated and use the loggedInAs to determine what functions/ buttons/ links/ screens are available to the user.
If you really want multiple browsers each simulating a different user, then you would change the loggedInAs to be an array or list and pass back and forth the simulated user identifier. Remember that all these browser windows are still using the same HTTPSession.
Also, with your current implementation, after the superUser clicks on the user_1 in the search results, if you are really replacing the session with the user_1's details, then when superUser tries to click on user_2 you should be displaying a 'You are not allowed to do this..'message because to you it would appear as if user_1 is trying to perform something only superUser can do.
Hope this makes sense.
[ June 16, 2008: Message edited by: Arun Natarajan ]