2 Replies Latest reply on Dec 14, 2009 12:59 PM by qihong87

    security context issue with RMIAdaptor

    qihong87 Dec 11, 2009 6:09 PM

      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!

      • 8100 Views
      • Tags:
        • 1. Re: security context issue with RMIAdaptor
          anil.saldhana
          anil.saldhana Dec 14, 2009 8:16 AM (in response to qihong87)
               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.
            • Actions
          • 2. Re: security context issue with RMIAdaptor
            qihong87 Dec 14, 2009 12:59 PM (in response to anil.saldhana)

            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?

              • Actions