security context issue with RMIAdaptor

[qihong87]

Hi JBoss developers,

I'm trying to get user groups info in the mbean code w/ JBoss app server version 5.1.0 GA. After some try and error, this info is available through 'SecurityAssociation.getSubject()' and/or 'SecurityContextAssociation.getSecurityContext()'. If invoke mbean via jmx-console (the web UI), it works fine. But if invoke via RMIAdaptor with AuthenticationInterceptor enabled (following instruction at http://www.jboss.org/community/wiki/SecureTheInvokers), then 'SecurityAssociation.getSubject()' returns null, and 'SecurityContextAssociation.getSecurityContext()' returns the security context with securityDomain=other, the expected is securityDomain=jmx-console. Noticed thtat SecurityAssociation.getPricipal()/getCredential() still returns correct username and password.

After debugging, found that AuthenticationInterceptor.invoke() set the right security context before invoking, but InvokerAdaptorService.invoke() (down the interceptor chain) set the security context to the default security domain. Is this a bug or there's some reason for this?

Here's the related code in InvokerAdaptorService.invoke() line 228

// Invoke the MBeanServer method via reflection
Method method = invocation.getMethod();
Object[] args = invocation.getArguments();
Principal principal = invocation.getPrincipal();
Object credential = invocation.getCredential();
Object value = null;
SecurityContext sc = SecurityActions.createSecurityContext(SecurityConstants.DEFAULT_APPLICATION_POLICY);
SecurityActions.setSecurityContext(sc);
// Associate the method
SecurityActions.pushSubjectContext(principal, credential, null);

Note that it always use default security domain, and pass null as subject to the SecurityActions.pushSubjectContext() call.

Thanks you so much!

[anil.saldhana]

     We assume the default security domain when we do not know what it is, at the time of creation of security context.  Once the call reaches the containers such as web, ejb, we are aware of the SD and set it appropriately on the thread local of the request path.

[qihong87]

Here's the stack trace:

      at hello.mbean.PropertyConfig.setProperty(Unknown Source:34)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
      at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
      at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:668)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.jmx.connector.invoker.InvokerAdaptorService.invoke(InvokerAdaptorService.java:263)
      at sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
      at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
      at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      at java.lang.reflect.Method.invoke(Method.java:597)
      at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:157)
      at org.jboss.mx.server.Invocation.dispatch(Invocation.java:96)
      at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:138)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)
      at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:140)
      at org.jboss.jmx.connector.invoker.SerializableInterceptor.invoke(SerializableInterceptor.java:74)
      at org.jboss.jmx.connector.invoker.AuthenticationInterceptor.invoke(AuthenticationInterceptor.java:104)
      at org.jboss.mx.server.Invocation.invoke(Invocation.java:90)

...

In this use case, the AuthenticationInterceptor.invoke(...) set the right security context, but InvokerAdaptorService.invoke(...) blindly assume the default security domain without check if there's one exist. This stack trace should make it clear. This is different code path than web or ejb.

Any thought?