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

[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.

[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.

[ryan.campbell]

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/[e-mail]%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.

[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. :)

[ryan.campbell]

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.

[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.

[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?