> > 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. > a) is a configurable attribute of the SecurityAssociation layer. You can choose to allow child threads to inherit the parent thread identity or not. b) The only issue with thread pools is leaking security credentials. If there is a single authentication layer as is the case for an embedded container, the thread identity simply needs to be established or cleared for the top level request. If this is not the case you need to establish and clear the identity on request boundaries.
> 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. > We have no plans on dropping the use of thread locals as there is simply no other easy mechanism for propagating the top level caller identity to the arbitrary components that can be called within the scope of a request. Integrate the JBoss/Jetty security layer as a request interceptor that receives a request start and end notification. You have to handled nested requests due to inclusion, but its not hard and you establish the caller identity on entry and clear it on completion of the top level request. This is how the tomcat integration is done. Scott _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
