dirk ooms wrote:
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.
So, if I understand correctly :
- the first level of authentication is, say, by company, and is meant basically to avoid
some unauthorised people accessing the website of each customer
- the second level of authentication is within this company's dedicated website, and is
meant to distinguish between different "actors" within that website.
- and within the website, there is an incentive for the actors to use their own id, and
not someone else's when they do something
As far as the "within the one website" thing is concerned, the other suggestions that you
have received seem the way to go. How you really integrate that into each action that
these people do, I don't know really.
But I would imagine that you could have some kind of applet within your web pages, which
reads a barcode from a barcode reader, and adds what it has read as a POST parameter,
before it submits the form to the server.
And then on the server, you pick up this special parameter, and switch the userPrincipal
on-the-fly, as they say.
As far as the first-level authentication is concerned, here is maybe a bit of lateral
thinking :
If you put an Apache httpd front-end in front of Tomcat, then you could install some form
of standard authentication at the Apache httpd level, which protects that website "in
general" with the "company login". Then only if that authentication succeeds, you would
proxy the calls to Tomcat (using mod_jk for instance). But Tomcat would know nothing
about this front-end authentication, and would not need to know.
Similarly, Apache httpd would never know - nor need to know - when the user at the Tomcat
level changes.
I think such a scheme would keep things nicely separated, and simplify the
whole design.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
