tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier ...@ice-sa.com>
Subject Re: user switching or application interacting with container based authentication
Date Thu, 24 May 2012 07:37:57 GMT
dirk ooms wrote:
> Hello,
> 
> we are running a web application with form based authentication. we now
> have a requirement to switch between users (for subsets of users) with a
> minimum of user interaction (log out and log in providing username &
> password is way too much work for the user). so i was thinking of
> providing each user with a badge with a unique barcode (a hash of
> username&password?) which they can scan into a dedicated field in the
> webpage and which will trigger the user switch. note that this barcode
> field will only be available once a person has logged in in the normal
> way (form based), so the user switch request is received within an
> authenticated session.
> 
> the difficult part of the story is how can i tell the 'container based
> authentication' that the current session is transferred to another user
> with possibly other roles OR how can i create a new session for the new
> user (so applying the correct authorization and providing a
> HttpServletRequest returning the correct values of getUserPrincipal()
> and isUserInRole()). the application is able to retrieve the user and
> its roles, but how can the application inform the container about this.
> 
> i've been googling and reading for hours now and i'm a bit lost
> (understatement) on how to proceed with this. it could also be the case
> that there are much better scenario's than the one i have in mind.
> 
> any hint on fast-user-switching or
> applications-interacting-with-container-based-authentication are very
> welcome.
> 

Without going into the technique itself, from your description above it looks to me as if

this is a scenario so different from what a standard AAA mechanism is designed to achieve,

that you are going to find yourself getting into a loop of increasing contradictions, if 
you try to fit this into the standard authentication mechanisms.
(In other words : you are going to be using code that has been carefully designed and 
perfected to do things well in one scenario, and try to do something else with it.  I 
would expect all kinds of side-effects, and an endless series of patches upon patches to 
avoid them).

Maybe the first question to ask : why do you need the user to be authenticated /to the 
servlet container/ in the first place ? when, and for what, do you use the return values 
of getUserPrincipal() and/or isUserInRole() ? (I mean really, deep down)

If you rethink the above, imagining that the user-id is just a request parameter like any

other <form> parameter (*), and that Tomcat itself has no knowledge of an authenticated

user, what breaks down ?



(*) which according to your own explanation above, you are going to have to do at some 
point anyway.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message