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 15:15:03 GMT
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org


Mime
View raw message