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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
