Andre, thanks for your thoughts on this. i agree that this issue brings me to 'a loop of increasing contradictions'. it's probably good to go one step back and explain the real-life requirement:
we have an application that is used by many small companies, each company has its own data and can have multiple users (typically 1 to 5). within a company there is a requirement to switch users in a fast way (e.g. using a badge or a fingerprint). think of a restaurant having 1 computer and several waiters. we want to trace what is done by which waiter and there is also an incentive for the waiter to switch users because his fee will be based on his logged activities. my reasoning was: i'll keep the standard proven AAA mechanism for the initial log in, but allow fast user switching within a company where there is more trust between users (which is security-wise probably a weak statement). still there is a need for some type of authentication because the users can have different roles. but this indeed leads to conflicts between the standard and the proprietary authentication/authorization mechanism. my current reasoning is: i need to keep a standard proven AAA mechanism also for fast user switching. correct? but how do i tackle this given that we now have form/container-based authentication. do i need a parallel standard container-based mechanism? what mechanism exists that allows to authenticate by scanning a barcode (i.e. a single (possibly long) string)? any pointer/suggestion will be much appreciated. dirk > > 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
