André Warnier wrote:
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.
Upon further thinking, of course you would not necessarily need an Apache httpd front-end
for this, and could do this all within Tomcat.
The container-level authentication comes first, before your webapp is even
called.
So that is your Tomcat-level authentication, by company.
Then you could still have some servlet filter (which runs after the container-level
authentication) to pick up this special POST parameter and do your "application-level"
authentication.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
