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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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
