tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Lin <tcw00l...@yahoo.com>
Subject RE: Threads in Tomcat 5
Date Thu, 01 Apr 2004 19:28:07 GMT
 
Ok, here's a quick overview of "single-sign-on" applications. It's prevalent in large platforms
and large corporations.
 
Say for example you're a bank and you have several branches. Each branch has their own IT
department and divisions. The pages users can view depend on their level of access privledge.
 In the typical single-sign-on application I am familiar with, the user only has to sign on
once. Normally this is done with LDAP or some kind of directory server. Basically, the database
(rdbms or ldap) contains information about what pages, sites and privledges the user has.
 
User joe signs on to the bank, but he also has an account with the IRA retirement department
of the bank. When Joe clicks on the link to see his IRA, it automatically sends a kerberos
like session token to the other system and redirects the user. To Joe, it all looks seamless,
but in reality he has been transferred from one system to another. User bob signs on to see
his account, but if Bob doesn't have an IRA account the system directs him to sign up for
an IRA.
 
It sounds like you don't need this level of complexity, but the principle is the same. There
are n pages, each with privledge requirements. If your pages already have the notion of access
privledges, the authentication portion becomes very simple. Otherwise retrofitting the website
becomes a tedious process. I hope that helps.
 
 peter
 


"Angelov, Rossen" <Rossen.Angelov@thomsonmedia.com> wrote:
I'll consider the HttpSession as an option and will implement sorting to see
if it work for us.

I'm not sure what you mean by single-sign-on application but our
authentication system uses a eRights, a product of eMETA, to authenticate
users and give access only to certain resources (usually pages) based on the
product and the policy information. Each http session is related to an
eRights session.

Ross

-----Original Message-----
From: Peter Lin [mailto:tcw00lfel@yahoo.com]
Sent: Thursday, April 01, 2004 12:26 PM
To: Tomcat Users List
Subject: RE: Threads in Tomcat 5



hit send too soon. Another approach which I've used and is common is to have
the notion of access control privledge like Unix file privledges. Each page
has a set privledge level and once the user is authenticated, the page
checks the users access level. there are numerous other variations on this
for single-sign-on applications.

peter


"Angelov, Rossen" wrote:
Well, the login requirements are not that simple to explain in few lines.
Some pages require authentication some don't, so it won't be appropriate to
do this when the HttpSession is first started. ThreadLocal is used to
identify the current thread (assuming that's for the current request) to get
the request parameters and create a hashtable for caching purpose (this was
done to speed up the registration process where over 30 demographic fields
are passed between pages). The same logic is used when logging in or
uploading a file with MultipartRequest.

The applications were originally created 2-3 years ago to work on iPlanet
and now I'm trying move them to Tomcat but it looks like there will be lot
of problems.

Ross


-----Original Message-----
From: Peter Lin [mailto:tcw00lfel@yahoo.com]
Sent: Thursday, April 01, 2004 11:21 AM
To: Tomcat Users List
Subject: Re: Threads in Tomcat 5



why do you want to use a thread to manage authentication? given the
requestProcessor threads are reused, it makes no sense to use the thread for
the mapping.

you're better off just authenticating the first time and setting the
HttpSession, rather than look up the thread. I'm probably missing something.

peter


"Angelov, Rossen" wrote:
Hi,

I'm trying to understand how exactly Tomcat 5 is organized to work with
threads. Is there any documentation on how the connector is using the
threads? What happens in the thread pool, how exactly the are threads picked
from the pool and what is their state? And what happens with the released
threads?

Our login application is having problems when retrieving data from the
requests. I was debugging the process by printing out the current thread
name and the request parameter values. 

Everything works fine when there is a different thread assigned to each
request:
request 1
current thread: http8080-Processor25
request 2
current thread: http8080-Processor23
request 3
current thread: http8080-Processor22

When an old thread is used for the new request, things don't work (usually
the wrong parameter values are returned) and the debug output looks like
this:
request 1
current thread: http8080-Processor25
request 2
current thread: http8080-Processor23
request 3
current thread: http8080-Processor25

Our application uses ThreadLocal to create a Hashtable with the current
request parameters as a cache storage. Very often the same thread is used
for more than one requests, the parameter values are retrieved from the
cache instead of using the new values. This completely breaks the logic and
the login process fails.

Thanks,
Ross

"This communication is intended solely for the addressee and is
confidential and not for third party unauthorized distribution."



---------------------------------
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today

"This communication is intended solely for the addressee and is
confidential and not for third party unauthorized distribution."



---------------------------------
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today

"This communication is intended solely for the addressee and is
confidential and not for third party unauthorized distribution."



---------------------------------
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway - Enter today
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message