7 Replies Latest reply on Apr 19, 2007 10:32 PM by anil.saldhana

    org.jboss.web.tomcat.security.RunAsListener

    pthurmond

      We've seen some contention in several different performance tests related to RunAsListener. See
      http://mail-archives.apache.org/mod_mbox/tomcat-dev/200702.mbox/<45DD8ADD.6040801%40apache.org>

      According to Remy in the thread above, the current implementation of InstanceSupport should not be used for anything other than debugging purposes. Maybe InstanceSupport could be changed to use some concurrent type, rather than array?

      --Phillip

        • 1. Re: org.jboss.web.tomcat.security.RunAsListener
          clebert.suconic

          or to use a ReadWriteLock accessing that array...

          From what I recall changing it is a really rare event...

          It would be better to protect it with a oswego.ReadWriteLock than synchronize the whole thing.

          • 2. Re: org.jboss.web.tomcat.security.RunAsListener
            anil.saldhana

            Remy has fixed the synchronization for tc6. We have to find a way by which we can push the run-as identity on to the SecurityAssociation, if we need to get away from instance stuff.

            • 3. Re: org.jboss.web.tomcat.security.RunAsListener

              I see Remy's fix now that you mention it. He fixed it shortly after replying to Dominik.

              http://mail-archives.apache.org/mod_mbox/tomcat-dev/200702.mbox/%3c20070222122404.F32BA1A981A@eris.apache.org%3e

              He removed the lock completely. That was easy. ;-)

              But it begs the question as to whether the Tomcat team will support this usage of InstanceListener.

              • 4. Re: org.jboss.web.tomcat.security.RunAsListener
                anil.saldhana

                 

                 <!-- Install an InstanceListener to handle the establishment of the run-as
                 role for servlet init/destroy events.
                 -->
                <InstanceListener>org.jboss.web.tomcat.security.RunAsListener</InstanceListener>
                


                We need to push the RunAsIdentity to aid usecases when the init/destroy methods need to make a call-out to other secured resources.

                I am not sure whether there is any replacement for the Instance support in tomcat. Unless Remy suggests a replacement, we have to hold on to this.

                Just the way, tc6 was fixed with the removal of the synchronized blocks, we should be able to fix tc55 for this. I do not understand why it was synchronized in the first place. :)



                • 5. Re: org.jboss.web.tomcat.security.RunAsListener

                  Yes, I see the requirement for this, no question there.

                  If Remy can't suggest a replacement, he needs to do the work required to make this a fully supported feature instead of claiming it is "just for debugging purposes."

                  Agreed, we should remove the synchronized block from TC5 as well, for updates to Branch_4_0.

                  • 6. Re: org.jboss.web.tomcat.security.RunAsListener
                    starksm64

                    If there is an InstanceEvent fired for every single touch of a web component then we need a better way to integrate the security state into the component lifecycle callouts. Removing the synchronization via a copy on write structure should be done regardless.

                    • 7. Re: org.jboss.web.tomcat.security.RunAsListener
                      anil.saldhana

                      I am seeing an issue that is a bit perplexing. I do not know how it was working before in JBoss4.

                      Here is the use case:
                      Testcase: org.jboss.test.web.test.WebIntegrationUnitTestCase
                      Scenarios: testUnsecureRunAsServlet, testUnsecureRunAsServletWithPrincipalName,testUnsecureRunAsServletWithPrincipalNameAndRoles

                      In my current pass at JBoss5, I am making use of a single threadlocal to contain the security context with push/pop mechanism.

                      Servlet: RunAsServlet
                      
                      init()
                      {
                       //I have a run-as defined, I am going to call a secure ejb
                      }
                      
                      service()
                      {
                       //I am going to call a secure ejb. run-as will be propagated
                      }
                      


                      In my sequence of calls, JaccContextValve which is set at the host level, establishes the security context on the thread local. After this, the SecurityAssociationValve will push the current run-as on to the established security context.

                      When the servlet is loaded, the init() method is preceded by an InstanceEvent("before_init") which will invoke the RunAsListener. I push the runas on to the security context. After the init method, there is an event for "after_init", which would pop the run as from the security context. So things work fine for the init() method secure ejb call.

                      There are issues from the service() method call in the servlet onto secure ejbs. The sequence of events are as follows for the service():
                      JaccContextValve - set the security context
                      SecurityAssociationValve - push run as
                      load the servlet
                      instanceevent:before-init - push run as
                      init()
                      instanceevent:after-init - pop run as
                      
                      At this time my thread local is devoid of any run as
                      
                      instanceevent:before_filter
                      instanceevent:after_filter
                      instanceevent:before_service
                      service()
                      instanceevent:after_service
                      


                      As you can see, there is no passage of the request through the valve chain between invocation of the init() and service() methods. I think this is the right sequence.

                      I can solve this usecase by adding push/pop of run as in the RunAsListener for InstanceEvent(before_service) and InstanceEvent(after_service).

                      Thoughts/suggestions?