8 Replies Latest reply on Apr 11, 2008 4:46 PM by anil.saldhana

    Why do we need a security context to access a local ejb?

      With the old SecurityAssociation we didn't need to login to access a local EJB.
      If the ejb was secured, it just failed because of the null principal,
      otherwise the request was allowed.

      21:00:26,618 ERROR [AbstractKernelController] Error installing to Start: name=jboss.test:service=CtsCmpServiceV1 state=Create mode=Manual requiredState=Installed
      java.lang.IllegalStateException: No security context for getPrincipal
       at org.jboss.ejb.plugins.local.BaseLocalProxyFactory$SecurityActions$1.getPrincipal(BaseLocalProxyFactory.java:535)
       at org.jboss.ejb.plugins.local.BaseLocalProxyFactory.invokeHome(BaseLocalProxyFactory.java:354)
       at org.jboss.ejb.plugins.local.LocalHomeProxy.invoke(LocalHomeProxy.java:133)
       at $Proxy87.create(Unknown Source)
       at org.jboss.test.cts.service.CtsCmpService.startService(CtsCmpService.java:53)
      


      Try deploying testsuite/output/lib/cts-v1cmp-sar.ear in JBoss5

        • 1. Re: Why do we need a security context to access a local ejb?
          anil.saldhana

          It has to be a bug if unsecured ejb access is not allowed. Please point me to the test in the test suite...

          • 2. Re: Why do we need a security context to access a local ejb?

            You don't need to run the testsuite, just copy that jar into deploy.

            This patch fixes it:

            Index: src/main/org/jboss/ejb/plugins/local/BaseLocalProxyFactory.java
            ===================================================================
            --- src/main/org/jboss/ejb/plugins/local/BaseLocalProxyFactory.java (revision 72017)
            +++ src/main/org/jboss/ejb/plugins/local/BaseLocalProxyFactory.java (working copy)
            @@ -532,18 +532,16 @@
             {
             SecurityContext sc = getSecurityContext();
             if(sc == null)
            - throw new IllegalStateException("No security context for getPrincipal");
            + return null;
             return sc.getUtil().getUserPrincipal();
            - //return SecurityAssociation.getPrincipal();
             }
            
             public Object getCredential()
             {
             SecurityContext sc = getSecurityContext();
             if(sc == null)
            - throw new IllegalStateException("No security context for getCredential");
            + return null;
             return sc.getUtil().getCredential();
            - //return SecurityAssociation.getCredential();
             }
            
             public SecurityContext getSecurityContext()
            @@ -561,9 +559,8 @@
             {
             SecurityContext sc = getSecurityContext();
             if(sc == null)
            - throw new IllegalStateException("No security context for getPrincipal");
            + return null;
             return sc.getUtil().getUserPrincipal();
            - //return SecurityAssociation.getPrincipal();
             }
             };
            
            @@ -573,9 +570,8 @@
             {
             SecurityContext sc = getSecurityContext();
             if(sc == null)
            - throw new IllegalStateException("No security context for getCredential");
            + return null;
             return sc.getUtil().getCredential();
            - //return SecurityAssociation.getCredential();
             }
             };
            


            I don't think this is full fix, since it should be roughly the same logic as
            org.jboss.proxy.SecurityInterceptor.

            SecurityInterceptor is used when a remote ejb proxy is operating in local optimization
            mode, while BaseLocalProxyFactory is used for purely local proxies.

            • 3. Re: Why do we need a security context to access a local ejb?
              anil.saldhana

              I had added the ISE to detect boundary cases. I think your patch looks correct. Can you please checkin the patch?
              http://jira.jboss.org/jira/browse/JBAS-5412

              • 4. Re: Why do we need a security context to access a local ejb?

                But what about the "runAs" stuff I see SecurityInterceptor?

                • 5. Re: Why do we need a security context to access a local ejb?
                  anil.saldhana

                  If an ejb defines a runas, then we push it on the security context for usage in the call path (thread level). So in the case of ejb local calls, if the sec context is null, then there is no run-as. But it is very very important for local calls. Currently, the magic code exists in the PreSecurityInterceptor (which I need to clean up a bit eventually) to detect the run as in local calls.

                  This was the question I had a few months back on the AS5 call( with you and Scott). I was told to aspectize security and not do anything with the invocation object.

                  • 6. Re: Why do we need a security context to access a local ejb?
                    anil.saldhana

                    I will verify the patch maybe on Tue or Wed once I finish some ejb3 stuff. :)

                    • 7. Re: Why do we need a security context to access a local ejb?

                      The problem I found was no SecurityContext.

                      But what about the case when there is one? What happens to the runAS?
                      The BaseLocalProxyFactory should be consistent with the org.jboss.proxy.SecurityInterceptor unless I'm missing something?

                      • 8. Re: Why do we need a security context to access a local ejb?
                        anil.saldhana

                        The PreSecurityInterceptor establishes the correct SC for both the local and remote invocations.

                        The reason BaseLocalProxyFactory does not do any runas processing is because the SecurityContext that is set on the threadlocal (I call it the SecurityContextAssociation) is available to the PreSecurityInterceptor since the call emanated in the same vm.

                        The proxy/SecurityInterceptor can be in the client vm. So I pick up the run as and send it in the SC over the invocation. This is a new feature (passing RunAs across VMs even though we have to attach additional trust semantics to inter-vm calls).