Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of aw@ice-sa.com designates
 212.85.38.228 as permitted sender)
Message-ID: <4FBE51BA.6050709@ice-sa.com>
Date: Thu, 24 May 2012 17:20:26 +0200
From: =?UTF-8?B?QW5kcsOpIFdhcm5pZXI=?= <aw@ice-sa.com>
Reply-To: Tomcat Users List <users@tomcat.apache.org>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: user switching or application interacting with container based
 authentication
References: <1337814101.1891.45.camel@earth>  <4FBDE555.2030702@ice-sa.com>
 <1337855462.1864.126.camel@earth> <4FBE5077.3090904@ice-sa.com>
In-Reply-To: <4FBE5077.3090904@ice-sa.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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