tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: user switching or application interacting with container based authentication
Date Thu, 24 May 2012 15:20:26 GMT
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" 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message