OK, I see what they are doing and will add a call to
SecurityAssociation.setPrincipal(null) after each request. Scott M Stark wrote: > This is why the Catalina security integration implements both > the Realm and Valve interfaces. The Realm callbacks establish > the authentication and the Valve limits the scope of the information > to the duration of the request. The thread of control returns to > the Catalina pool with no thread local association. The Tomcat 3.2 > security integration does the same thing, but it a lot more > work because the integration interface is not as clean. > > xxxxxxxxxxxxxxxxxxxxxxxx > Scott Stark > Chief Technology Officer > JBoss Group, LLC > xxxxxxxxxxxxxxxxxxxxxxxx > ----- Original Message ----- > From: "Greg Wilkins" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; "jules" <[EMAIL PROTECTED]> > Sent: Monday, February 25, 2002 4:30 PM > Subject: [JBoss-dev] Security problem in authentication model. > > > >>There is a problem with the use of ThreadLocals to record Authentication >>when the client (in this case Jetty) is using ThreadPools. >> >>I have previously mentioned this, but now I have confirmation that it is >>a problem for a Client. >> >>He created a small thread pool for the listener (4 threads), then >>used 4 browsers to hit authenticated pages and authenticated >>with a different user for each browser. >> >>The effect of this was for the JBoss authentication mechanism to >>create ThreadLocal authentications for each of these threads. >> >>He then got new browsers and started hitting unauthenticated >>pages that reported the request and EJB auth details. These >>new requests receive random EJB authentication depending on >>which thread from the thread pool they are allocated: >> >> >>23:33:25,434 INFO [Default] request.getUserPrincipal=null; >> >>ctx.getCallerPrincipal().getName()=comercial >> >>23:33:25,464 INFO [Default] request.getUserPrincipal=null; >> >>ctx.getCallerPrincipal().getName()=comercial >> >>23:33:38,333 INFO [Default] request.getUserPrincipal=null; >> >>ctx.getCallerPrincipal().getName()=cliente >> >>23:33:38,373 INFO [Default] request.getUserPrincipal=null; >> >>ctx.getCallerPrincipal().getName()=cliente >> >>23:34:46,341 INFO [Default] request.getUserPrincipal=null; >> >>ctx.getCallerPrincipal().getName()=cliente >> >>23:34:46,371 INFO [Default] request.getUserPrincipal=null; >> >>ctx.getCallerPrincipal().getName()=cliente >> >>23:34:57,186 INFO [Default] request.getUserPrincipal=null; >> >>ctx.getCallerPrincipal().getName()=admin >> >>23:34:57,236 INFO [Default] request.getUserPrincipal=null; >> >>ctx.getCallerPrincipal().getName()=admin >> >> >>We need a mechanism to unauthenticate Threads, so the Jetty can >>call this after each request. >> >>Note that it is not an option to get rid of the ThreadPool as that >>would be a HUGE performance hit. >> >> >>regards >> >> >>-- >>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 > -- 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
