11 Replies Latest reply on Sep 10, 2013 3:06 PM by Rafael Vanderlei de Souza

    Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1

    Rafael Vanderlei de Souza Newbie

      Hi all,

       

      I am migrating some applications from JBoss AS 7.1.1-Final to JBoss EAP 6.1.0.GA and I am having trouble when trying to invoke methods on a EJB deployed inside a EAR from WEB Module deployed inside the same EAR.

       

      The code looks like follows:

       

              Context context = new InitialContext();

              MyEJBInterface ejb = (MyEJBInterface)context.lookup("java:app/moduleName/ejbName!xxx.xxx.xxx.MyEJBInterface");

              ejb.doSomething();

       

      Then, when I try to run it, I get the following exception:

       

      javax.ejb.EJBAccessException: JBAS013323: Invalid User

          at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:54)

          at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:45)

          at java.security.AccessController.doPrivileged(Native Method)

          at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:74)

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

          at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

          at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59)

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

          at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

          at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55)

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

          at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45)

          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288)

          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)

          at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165)

          at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:222)

          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181)

          at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58)

          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

          at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83)

          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

          at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42)

          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

          at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125)

          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183)

          at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253)

          at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198)

          at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)

          at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)

          at $Proxy79.doSomething(Unknown Source)

       

      Also, I don't know if there is a connection to the problem, but as my application invokes remote EJBs deployed in other instances of EAP 6.1, I have configured jboss-ejb-client.xml, which looks like follows:

       

      <?xml version="1.0" encoding="UTF-8"?>

      <jboss-ejb-client xmlns="urn:jboss:ejb-client:1.0">

          <client-context>

              <ejb-receivers>

                  <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-app1" />

                  <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-app2" />

                  <remoting-ejb-receiver outbound-connection-ref="remote-ejb-connection-app3" />

              </ejb-receivers>

          </client-context>

      </jboss-ejb-client>

       

      I'm stuck because the exact same code and configuration works fine on AS 7.1.1-Final and EAP 6.0.0, but is failing on EAP 6.1.0.GA and I'd really appreciate if anyone could help me on this.

       

      If you need more information, please let me know.

       

      Regards,

      Rafael.

        • 1. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
          jaikiran pai Master

          What does the bean that being invoked, look like?

           

          Also, take a look at this and see if it's relevant to your case Securing EJBs - JBoss AS 7.2 - Project Documentation Editor

          • 2. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
            Rafael Vanderlei de Souza Newbie

            Hi, Jaikiran.

             

            Thanks for the response.

             

            The link you provided contains really useful information. I was unaware of those changes regarding secured EJBs starting at JBoss AS 7.2.x. But, still, I think the information in that link is not entirely relevant to the problem I'm facing.

             

            In fact, my EJB has some security annotations.. here is how it looks like:

             

            @Stateless(name="ejbName")

            @SecurityDomain("mySecurityDomain")

            public class MyEjb implements MyEJBInterface {

            ...

                @RolesAllowed({"ROLE_1","ROLE_2"})

                public void someSecuredMethod() { ... }

             

                //That's the method I'm trying to invoke from the WEB Module.

                public void doSomething() { ... }

            ...

            }

             

            As it seems to be some problem regarding Security Domain, here it's how it's configured on standalone.xml

             

            <subsystem xmlns="urn:jboss:domain:security:1.2">

               <security-domains>

                  ...

                              <security-domain name="mySecurityDomain">

                                <authentication>

                                    <login-module code="xxx.xxx.MyCustomLoginModule" flag="required />

                                </authentication>

                            </security-domain>

               </security-domains>

            </subsystem>

             

            The rest of security subsystem contains configuration that comes out-of-the-box in EAP 6.1.0.GA (with, other, jboss-web-policy, and jboss-ejb-policy).

             

            My <subsystem xmlns="urn:jboss:domain:ejb3:1.4"> is also just as it comes out-of-the-box. Following the link you provided ("Securing EJBs"), I even tried changing configuration as follows, but had no success:

             

            <default-security-domain value="mySecurityDomain"/>

            <default-missing-method-permissions-deny-access value="false"/>

             

             

             

            If we look back at the exception message "javax.ejb.EJBAccessException: JBAS013323: Invalid User" , I think it's more an authentication problem rather than an authorization problem. But I'm sure I'm logged in the Web Module, using "MyCustomLoginModule" declared on "mySecurityDomain", but somehow I feel like it's not being propagated to the EJB Module's SecurityContext.

             

            Maybe it's some silly mistake made by myself, as I must confess I don't really master security details, specially when it comes to SecurityContext propagations

             

            But as I told before, everything I showed so far works in AS 7.1.1 and EAP 6.0, but is failing in EAP 6.1.

             

            Am I missing something? Do you need any more information?

             

            Again, thanks for the help.

            • 3. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
              Rafael Vanderlei de Souza Newbie

              Hi, I fixed the problem but in the end I found what it seems to be a bug in EAP 6.1, unless it's actually the expected behaviour and I'm messing the understanding of the configuration.

               

              In order to investigate a little further, I enabled TRACE level for <logger category="org.jboss.security"> which printed following stacktrace in server.log, when tyring to invoke a method in the secured EJB (sorry for my server being started with user.language=pt so a few localized messages are printed in Portuguese):

               

              09:43:21,391 DEBUG [org.jboss.security] (http-/0.0.0.0:8080-1) PBOX000206: Login failure: javax.security.auth.login.LoginException: n䯠顰ossl localizar a classe LoginModule: xxx.xxx.MyCustomLoginModule from [Module "deployment.MyEAR.ear.myEJBModule.jar:main" from Service Module Loader]

                  at javax.security.auth.login.LoginContext.invoke(LoginContext.java:808) [rt.jar:1.6.0_45]

                  at javax.security.auth.login.LoginContext.access$000(LoginContext.java:186) [rt.jar:1.6.0_45]

                  at javax.security.auth.login.LoginContext$4.run(LoginContext.java:683) [rt.jar:1.6.0_45]

                  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_45]

                  at javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680) [rt.jar:1.6.0_45]

                  at javax.security.auth.login.LoginContext.login(LoginContext.java:579) [rt.jar:1.6.0_45]

                  at org.jboss.security.authentication.JBossCachedAuthenticationManager.defaultLogin(JBossCachedAuthenticationManager.java:408) [picketbox-infinispan-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                  at org.jboss.security.authentication.JBossCachedAuthenticationManager.proceedWithJaasLogin(JBossCachedAuthenticationManager.java:345) [picketbox-infinispan-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                  at org.jboss.security.authentication.JBossCachedAuthenticationManager.authenticate(JBossCachedAuthenticationManager.java:333) [picketbox-infinispan-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                  at org.jboss.security.authentication.JBossCachedAuthenticationManager.isValid(JBossCachedAuthenticationManager.java:146) [picketbox-infinispan-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                  at org.jboss.as.security.service.SimpleSecurityManager.authenticate(SimpleSecurityManager.java:436) [jboss-as-security-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.as.security.service.SimpleSecurityManager.push(SimpleSecurityManager.java:337) [jboss-as-security-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:49) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.as.ejb3.security.SecurityContextInterceptor$1.run(SecurityContextInterceptor.java:45) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_45]

                  at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:74) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                  at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                  at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                  at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                  at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                  at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                  at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                  at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:222) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                  at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                  at com.sun.proxy.$Proxy79.doSomething(Unknown Source)

               

              Once I read such stacktrace, the problem became easy to solve, which I made just by adding the dependency to the module that contains "xxx.xxx.MyCustomLoginModule".

               

              This fixed the problem of the authentication, but made me wonder why it wasn't necessary when deploying on EAP 6.0. I'll leave this question to another post to make this one clean to be marked as an answer.

               

              Also, after I fixed authentication problem, it pointed me to a new problem, regarding to authorization, which I think that may be a bug in EAP 6.1, if I understand the configuration correctly. I'll leave it to another post too.

              • 4. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
                Rafael Vanderlei de Souza Newbie

                In the last post I said I would leave 2 notes to next posts, one related to a question and other related to what seems to be a bug in EPA 6.1. In this post I'll describe the question and I'll leave the "bug" description to the next post.

                 

                Before continue let me summarize what has been discussed so far. The context is:

                 

                1. I have a EAR that contains a WAR module and a EJB Module;

                2. In EJB Module, I have a EJB annotated with @SecurityDomain("mySecurityDomain") with some methods annotated with @RollesAllowed and other methods without any security metadata.

                3. In Web Module, I have jboss-web.xml configuring <security-domain>java:/jaas/mySecurityDomain</security-domain>

                4. In standalone.xml, "mySecurityDomain" uses a custom JAAS LoginModule that is installed somewhere under ${EAP6.1}/modules and is referenced in the EAR's jboss-deployment-structure.xml like following:

                <jboss-deployment-structure>

                ...

                <deployment>

                ...

                <dependencies>

                ...

                <module name="module_containing_custom_login_module" />

                </dependencies>

                </deployment>

                ...

                <sub-deployment name="myWebModule.war">

                <dependencies>

                ...

                <module name="module_containing_custom_login_module" />

                </dependencies>

                </sub-deployment>

                ...

                </jboss-deployment-structure>

                 

                This configuration worked on EAP 6.0, even without adding the "custom login module" dependency to "myEJBModule". and just by upgrading to EAP 6.1, AS was not able to find my custom login module from within the EJB Module.

                 

                I would like to understand what has changed so the same configuration stopped working on EAP 6.1 (maybe something changed on the way EAP adds implicit dependency to deployments)

                 

                That even makes me wonder if security was actually happening on EAP 6.0 or if it was somehow failing silently.

                 

                I'd appreciate if you could please clarify my understanding on this.

                • 5. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
                  Rafael Vanderlei de Souza Newbie

                  Now about the possible bug (unless it's supposed to be a feature and I'm misunderstanding)...

                   

                  In standalone.xml the configuration <default-security-domain value="mySecurityDomain"/> inside <subsystem xmlns="urn:jboss:domain:ejb3:1.4"> is dominant over @SecurityDomain annotated on the EJB class, but is correctly overriden by jboss-ejb3.xml.

                   

                  What I mean is that if I have

                   

                  <default-security-domain value="ABC"/>

                   

                  And then I have @SecurityDomain("XYZ"), EAP 6.1 is always considering security-domain "ABC".

                   

                  While if I have the following, in jboss-ejb3, EAP 6.1 considers security-domain "XYZ":

                   

                      <assembly-descriptor>

                          <s:security>

                              <ejb-name>MyEJB</ejb-name>

                              <s:security-domain>XYZ</s:security-domain>

                          </s:security>

                      </assembly-descriptor>

                   

                  Is that what is expected to happen, for some reason, or is it actually a bug?

                  • 6. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
                    jaikiran pai Master

                    Rafael Vanderlei de Souza wrote:

                     


                    <default-security-domain value="ABC"/>

                     

                    And then I have @SecurityDomain("XYZ"), EAP 6.1 is always considering security-domain "ABC".

                     

                    What is the fully qualified name of that annotation? It should be @org.jboss.ejb3.annotation.SecurityDomain

                    • 7. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
                      Rafael Vanderlei de Souza Newbie

                      Hi, Jaikiran. Thanks again.

                       

                      I just don't know where to dig my head into right now.

                       

                      I was sure I was using JBoss' specific @SecurityDomain, and actually I am, but this is legacy code which was running on JBoss 4.2.2, and it was importing @org.jboss.annotation.security.SecurityDomain from dependency jboss:jboss-annotations-ejb3:4.2.2.GA

                       

                      While migrating to EAP I hadn't noticed that the package had changed. After reading your post, I updated the dependency to org.jboss.ejb3:jboss-ejb3-ext-api:2.1.0 and imported @org.jboss.ejb3.annotation.SecurityDomain as you mentioned and now JBoss is respecting the security-domain configured in such annotation, as expected. So.. the bug I suspected was... myself.

                       

                      Unfortunately, I was really happy while running the application in my local environment, but in the enterprise environment I'm now facing a weard problem.

                       

                      In local machine I configure and start JBoss in standalone mode, and everything regarding security is working as expected. But when I deploy to the enterprise environment, where JBoss runs on domain mode, authorization is failing for methods annotated with @RolesAllowed.

                       

                      What is more weard about it is that the same role required to call the secured EJB method is also required to allow access to the page in WEB module that contains a button that triggers the method calls that will end in the secured method in EJB module.

                       

                      Digging to find a solution, I enabled TRACE log level for some JBoss components and found a little difference in the log entries displayed between standalone mode environment and domain mode environment.

                       

                      In standalone mode, I had this:

                       

                      11:10:37,194 DEBUG [org.jboss.security] (http-/0.0.0.0:8080-4) PBOX000291: Method: doSomething, interface: Remote, required roles: Roles(ROLE_FOR_DOSOMETHING,)

                      11:10:37,197 TRACE [org.jboss.security.audit] (http-/0.0.0.0:8080-4) [Success]Source=org.jboss.security.plugins.javaee.EJBAuthorizationHelper;Action=authorization;Resource:=[org.jboss.security.authorization.resources.EJBResource:contextMap={policyRegistration=null}:method=public abstract void xxx.xxx.MyEJB.doSomething():ejbMethodInterface=Remote:ejbName=MyEJBName:ejbPrincipal={my_custom_principal_details}:MethodRoles=Roles(ROLE_FOR_DOSOMETHING,):securityRoleReferences=null:callerSubject=Subject:...:callerRunAs=null:callerRunAs=null:ejbRestrictionEnforcement=false:ejbVersion=2.0];policyRegistration=null;

                       

                      While in domain mode, I had this:

                       

                      10:31:01,472 DEBUG [org.jboss.security] (ajp-/10.0.148.99:8609-4) PBOX000291: Method: doSomething, interface: Remote, required roles: Roles(ROLE_FOR_DOSOMETHING,)

                      10:31:01,473 DEBUG [org.jboss.security] (ajp-/10.0.148.99:8609-4) PBOX000292: Insufficient method permissions [principal: { my_custom_principal_details }, EJB name: MyEJBName, method: doSomething, interface: Remote, required roles: Roles(ROLE_FOR_DOSOMETHING,), principal roles: Roles(), run-as roles: null]

                      10:31:01,473 DEBUG [org.jboss.security] (ajp-/10.0.148.99:8609-4) PBOX000299: Required module org.jboss.security.authorization.modules.DelegatingAuthorizationModule failed

                      10:31:01,482 DEBUG [org.jboss.security] (ajp-/10.0.148.99:8609-4) PBOX000325: Authorization processing error: org.jboss.security.authorization.AuthorizationException: PBOX000017: Acces denied: authorization failed

                          at org.jboss.security.plugins.authorization.JBossAuthorizationContext.invokeAuthorize(JBossAuthorizationContext.java:268) [picketbox-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                          at org.jboss.security.plugins.authorization.JBossAuthorizationContext.access$000(JBossAuthorizationContext.java:71) [picketbox-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                          at org.jboss.security.plugins.authorization.JBossAuthorizationContext$1.run(JBossAuthorizationContext.java:147) [picketbox-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                          at java.security.AccessController.doPrivileged(Native Method) [rt.jar:1.6.0_31]

                          at org.jboss.security.plugins.authorization.JBossAuthorizationContext.authorize(JBossAuthorizationContext.java:143) [picketbox-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                          at org.jboss.security.plugins.JBossAuthorizationManager.internalAuthorization(JBossAuthorizationManager.java:429) [picketbox-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                          at org.jboss.security.plugins.JBossAuthorizationManager.authorize(JBossAuthorizationManager.java:115) [picketbox-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                          at org.jboss.security.plugins.javaee.EJBAuthorizationHelper.authorize(EJBAuthorizationHelper.java:318) [picketbox-4.0.17.Final-redhat-1.jar:4.0.17.Final-redhat-1]

                          at org.jboss.as.security.service.SimpleSecurityManager.authorize(SimpleSecurityManager.java:255) [jboss-as-security-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.as.ejb3.security.AuthorizationInterceptor.processInvocation(AuthorizationInterceptor.java:112) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                          at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:76) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                          at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                          at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:59) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                          at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                          at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:55) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                          at org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                          at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61) [jboss-invocation-1.1.1.Final-redhat-2.jar:1.1.1.Final-redhat-2]

                          at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:165) [jboss-as-ee-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.as.ejb3.remote.LocalEjbReceiver.processInvocation(LocalEjbReceiver.java:222) [jboss-as-ejb3-7.2.0.Final-redhat-8.jar:7.2.0.Final-redhat-8]

                          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:181) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocation(EJBObjectInterceptor.java:58) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocation(EJBHomeInterceptor.java:83) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.TransactionInterceptor.handleInvocation(TransactionInterceptor.java:42) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.ReceiverInterceptor.handleInvocation(ReceiverInterceptor.java:125) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBClientInvocationContext.sendRequest(EJBClientInvocationContext.java:183) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBInvocationHandler.sendRequestWithPossibleRetries(EJBInvocationHandler.java:253) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:198) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144) [jboss-ejb-client-1.0.21.Final-redhat-1.jar:1.0.21.Final-redhat-1]

                          at $Proxy82.doSomething(Unknown Source)    at xxxxx.SomeClassInWebModule.doSomethingWeb(SomeOtherClassInWebModule.java:80)

                       

                      10:31:01,492 TRACE [org.jboss.security.audit] (ajp-/10.0.148.99:8609-4) [Failure]Source=org.jboss.security.plugins.javaee.EJBAuthorizationHelper;Action=authorization;Exception:=PBOX000017: Acces denied: authorization failed ;Resource:=[org.jboss.security.authorization.resources.EJBResource:contextMap={policyRegistration=null}:method=public abstract void xxx.xxx.MyEJB.doSomething():ejbMethodInterface=Remote:ejbName=MyEJBName:ejbPrincipal={my_custom_principal_details}:MethodRoles=Roles(ROLE_FOR_DOSOMETHING,):securityRoleReferences=null:callerSubject=Subject:...:callerRunAs=null:callerRunAs=null:ejbRestrictionEnforcement=false:ejbVersion=2.0];policyRegistration=null;

                       

                       

                       

                      The line I highlighted gives a tip about a required module failing, but it only happens in domain mode. Is there something else I must configure in domain mode to get authorization working? I don't know where to look at to fix it.

                       

                      Any help on this would be really appreciated.

                      • 8. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
                        Rafael Vanderlei de Souza Newbie

                        Hi, I found new information that might be helpful.

                         

                        I finally figured out what was different between my local environment and the enterprise environment.

                         

                        In local machine, security-domain is configured without authentication cache (no cache-type attribute was defined)

                         

                        While in enterprise environment, the administrator had configured security-domain with cache-type="default".

                         

                        I tested changing the environment configuration to disable authentication cache for the security-domain and everything (authentication/authorization) worked as expected.

                         

                        Now, my question is "why isn't it working when using default authentication cache? What are the requirements that my application must meet to allow the use of such a feature?"

                         

                        Is there good documentation about how this cache actually works, so I can better understand and decide whether to use ir or not?

                         

                        Thanks.

                        • 9. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
                          jaikiran pai Master

                          Rafael Vanderlei de Souza wrote:

                           

                          Hi, I found new information that might be helpful.

                           

                          I finally figured out what was different between my local environment and the enterprise environment.

                           

                          In local machine, security-domain is configured without authentication cache (no cache-type attribute was defined)

                           

                          While in enterprise environment, the administrator had configured security-domain with cache-type="default".

                           

                          I tested changing the environment configuration to disable authentication cache for the security-domain and everything (authentication/authorization) worked as expected.

                           

                          That's new to me. You might find more audience for that question if you create a separate thread with the relevant details.

                          • 10. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
                            jaikiran pai Master

                            By the way, do you have custom principal implementation in your application? If yes, then have you properly implemented in the equals() and hashCode() methods in that custom principal (related Re: Every single remote ejb call starts full authentication process with SecurityDomain cache-type="default")

                            • 11. Re: Exception when trying to invoke EJB method from WEB Module to EJB Module on EAP 6.1
                              Rafael Vanderlei de Souza Newbie

                              After some time debugging picketbox-4.0.17-Final source code I found what was wrong.

                               

                              At some point in the execution, JBoss gets to the following method of org.jboss.security.plugins.JBossAuthorizationManager:

                               

                              private RoleGroup copyGroups(RoleGroup source, Group toCopy)

                                 {

                                    if(toCopy == null)

                                       return source;

                                    if(source == null && toCopy != null)

                                       source = this.getEmptyRoleGroup();

                                    Enumeration<? extends Principal> en = toCopy.members();

                                    while(en.hasMoreElements())

                                    {

                                       source.addRole(new SimpleRole(en.nextElement().getName()));

                                    }

                                    

                                    return source;

                                 }

                               

                              The RoleGroup returned by this method is supposed to contain all roles the authenticated user has and afterwards JBoss uses this RoleGroup to check againts the role required to access a resource (in this case a EJB method).

                               

                              While debugging, I noticed that running without SecurityDomain authentication cache, this method was returning a RoleGroup containing all Roles associated to the authenticated Subject, but when SecurityDomain was configured with cache-type="default", the RoleGroup returned was Empty (the one created at JBossAuthorizationManager.getEmptyRoleGroup()), even in the case that Group 'toCopy' was full of members added. Still debugging, I noticed the problem was actually in the condition on the while block... en.hasMoreElements() was always returning false. Then I suspected of the Group.members() implementation and finally found what was wrong.

                               

                              The object passed to the "toCopy" argument of copyGroups method above is a custom implementation of java.security.acl.Group provided by a third party department, so it took a while for me to get access to the code. This implementation was really poor, something like follows:

                               

                                 private Enumeration<Principal> members;

                                 private Vector membersVector = new Vector();

                               

                                 public boolean addMember(Principal user) {  

                                      membersVector.add(user);

                                      members = membersVector.elements();

                                      return true;

                                  }

                               

                                  public boolean removeMember(Principal user) {

                                      membersVector.remove(user);

                                      members = membersVector.elements();

                                      return true;

                                  }

                               

                                 public Enumeration<Principal> members() {

                                      return members;

                                  }

                               

                              As we can see, this implementation was 'very wrongly' keeping an instance attribute with a Enumeration object. Everytime addMember or removeMember was called, a new Enumeration was being created and set to this attribute. And the members() implementation was just returning this Enumeration. So, by design, it was possible to iterate over members() only once (and JBoss had already done that in the WEB Module). Next attempts to iterate over the custom Group.members() were always behaving like there are no more elements.

                               

                              So why was it working without authentication cache? I guess it's because a new Subject was always being instantiated and also a new Custom Group with not yet iterated members. On the other hand, when using cache-type="default", the Subject returned from the cache had that *&*%* bugged custom Group.

                              1 of 1 people found this helpful