Jules Gosnell wrote: > isAuthenticated() is now in. It reauthenticates every time it is called, using a > password cached from the last call to authenticate(). This will have been from the > original request thread.
Cool, but it will have the effect of authorizing any thread that is allocated to a request for that session. This will make things work (but maybe too well). > I haven't pursued the threadlocal issue. I do not explicitly set them up, so I am > assuming someone else is responsible for tidying them up..... Of course, I could be > wrong.... :-) I still think that somebody needs to look at this. Using ThreadLocals to authorize threads is probably cool for passing control to third party objects and allowing them to also be authenticated. However it simply does not address the problems of a) Threads started by those threads (should you authorize threadgroups???) and b) Thread pools. Currently over time, every thread in a thread pool will get authorized for some user or other and there is no mechanism that I know to remove that authorization. Thread pooling is such common practise, that any security mechanism must handle it. Either the Jboss mechanism needs to stop using ThreadLocals, or a bullet proof mechanism needs to be provided for removing authorization from threads that are returned to the pools. cheers > Greg Wilkins wrote: > > >>Well the idea of an extra call is that it can be implemented simply >>for most situations (return true). >> >>For JBoss where a) authorization can be revoked and b) the thread locals >>need to be setup, you will have to reauthenticate on every call to isAuthenticated. >> >>You will have to cache the info you need from the authenticate() request. >>As you say, you can cache the request, only the data you get from it. >> >>Are the JBoss guys discussing the ThreadLocal issue at all?? >> >>cheers >> >>Jules Gosnell wrote: >> >> >>>Do you mean : >>> >>>1. re-authenticate() on every call to isAuthenticated() - if so from where am >>>I meant to pick up the HttpRequest (needed for setting Attributes to support >>>e.g JAAS), and the password ? The passwd could be cached from the initial >>>authentication, but the request can't. But then if they were the same call, >>>why have 2 different ones in the API ? >>> >>>2. cache result of authenticate() and return that. >>> >>>I figure you mean (1), hence the question. >>> >>> >>>Jules >>> >>> >>>Greg Wilkins wrote: >>> >>> >>> >>>>I have added isAuthenticated call to UserPrinciple to check if a >>>>session is still authenticated. >>>> >>>>You will need to implement this to call the JBoss authentication mechanism >>>>again, which should fix most of our problems. >>>> >>>>I still think the JBoss ThreadLocals suck - and don't know how we can >>>>get rid of them??? >>>> >>>>-- >>>>Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 >>>>Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631 >>>>http://www.mortbay.com AU Phone: +61-(0)2 98107029 >>>> >>>> >>> >>>_________________________________________________________ >>>Do You Yahoo!? >>>Get your free @yahoo.com address at http://mail.yahoo.com >>> >>> >>> >>-- >>Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 >>Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631 >>http://www.mortbay.com AU Phone: +61-(0)2 98107029 >> > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > -- Greg Wilkins<[EMAIL PROTECTED]> GB Phone: +44-(0)7092063462 Mort Bay Consulting Australia and UK. Mbl Phone: +61-(0)4 17786631 http://www.mortbay.com AU Phone: +61-(0)2 98107029 _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
