[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
RE: [JBoss-dev] Security problem in authentication model.
Yeah that is a serious problem, we need Session based authentication. marcf |-Original Message- |From: [EMAIL PROTECTED] |[mailto:[EMAIL PROTECTED]]On Behalf Of Greg |Wilkins |Sent: Monday, February 25, 2002 4:31 PM |To: [EMAIL PROTECTED]; jules |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 ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Security problem in authentication model.
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. Scott Stark Chief Technology Officer JBoss Group, LLC - 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
Re: [JBoss-dev] Security problem in authentication model.
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. Scott Stark Chief Technology Officer JBoss Group, LLC - 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
Re: [JBoss-dev] Security problem in authentication model.
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. Scott, Talking of Catalina security - there have been quite a few posts in the forums about how to use Catalina security with standalone JBoss, as is possible in Tomcat 3.2. There doesn't seem to be an obvious way of getting hold of the current security information (username/password) from a Valve in order to set up the security association with JBoss. I'm not even sure if it's possible at all, as it seems likely that the Catalina authenticators will junk the password once the user's been authenticated, and it won't be available to subsequent requests. Do you have any ideas from your work on the integrated security? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
Re: [JBoss-dev] Security problem in authentication model.
Probably the easiest way would be to subclass the SingleSignOn Valve and use the session based cache to obtain the authentication information. Scott Stark Chief Technology Officer JBoss Group, LLC - Original Message - From: Luke Taylor [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Monday, February 25, 2002 6:48 PM Subject: Re: [JBoss-dev] Security problem in authentication model. 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. Scott, Talking of Catalina security - there have been quite a few posts in the forums about how to use Catalina security with standalone JBoss, as is possible in Tomcat 3.2. There doesn't seem to be an obvious way of getting hold of the current security information (username/password) from a Valve in order to set up the security association with JBoss. I'm not even sure if it's possible at all, as it seems likely that the Catalina authenticators will junk the password once the user's been authenticated, and it won't be available to subsequent requests. Do you have any ideas from your work on the integrated security? Luke. -- Luke Taylor. Monkey Machine Ltd. PGP Key ID: 0x57E9523Chttp://www.mkeym.com ___ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
