2 Replies Latest reply on Apr 19, 2009 2:13 AM by jaikiran

    JBoss 5.0.1 stubbornly ignores application-policy in login-c

      Hi. I am enjoying JBoss 5.0.1 JAAS security during implementing EJB3 application server beans and client.

      I cannot use EJB3 client container, since it tries to access server immediately, before any piece of my code is exceuted. So, i do InitialContext.lookup(...) instead:

      try{
       SecurityClient securityClient = SecurityClientFactory.getSecurityClient();
       securityClient.setSimple("vpumpkin", "vpumpkin");
       securityClient.login();
      
       Context context = new InitialContext();
       BlankService service = context.lookup("IB-Automation/BlankServiceImpl/remote-cool.ib.service.BlankService");
      } catch(...){...}

      In this code i believe, that login/passwor pair "vpumpkin"/"vpumpkin" is delivered up to JBoss server somehow by the BlankService proxy, even if i do login() in one thread, and invoke business method of EJB in another one. Right?

      On the server-side i have the BlankServiceImpl bean:
      @SecurityDomain(value = "IB-Automation")
      @DeclareRoles(value = {"Blank-Reader", "Blank-Writer"})
      @Stateless
      public class BlankServiceImpl implements BlankService {
      
       @Override
       @RolesAllowed({"Blank-Writer"})
       public long persist(StrictBlankEntity blank) {...}
      
       @Override
       @RolesAllowed({"Blank-Reader", "Blank-Writer"})
       public List<StrictBlankEntity> list(){...}
      
      }


      I have updated the ${jboss-home}/server/default/conf/login-config.xml in the way it is described in

      http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Server_Configuration_Guide/4/html/Security_on_JBoss-Defining_Security_Domains.html

      and in

      http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Server_Configuration_Guide/4/html/Using_JBoss_Login_Modules-DatabaseServerLoginModule.html

      exactly after <application-policy name="other"/> declaration:
      <application-policy name="IB-Automation">
       <authentication>
       <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
       <module-option name="dsJndiName">MUST_FAIL_HERE_SINCE_IT_IS_WRONG!!!</module-option>
       <module-option name="principalsQuery">
       MUST_FAIL_HERE_SINCE_IT_IS_WRONG_TOO!!!
       </module-option>
       <module-option name="rolesQuery">
       MUST_FAIL_HERE_SINCE_IT_IS_WRONG_AS_WELL!!!
       </module-option>
       </login-module>
       </authentication>
       </application-policy>

      Having all these "MUST_FAIL_HERE...!!!" i expect juicy exceptions in console at the moment of retrieving datasource from JNDI or on attempts to get user info from database(anyway, with correct values it doesn't work).

      I start client, and see ... exactly the result of BlankServiceImpl.list() method, like nothing prevents me to access it! Cool! :D

      Well, ok... It seems, that @SecurityDomain(value = "IB-Automation") annotation is absolutely useless here. And it might work with old jboss.xml like they claim in

      http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Server_Configuration_Guide/4/html/The_JBoss_Security_Model-Enabling_Declarative_Security_in_JBoss_Revisited.html ?

      Let's check it!
      <?xml version="1.0" encoding="UTF-8"?>
      <!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 4.2//EN" "http://www.jboss.org/j2ee/dtd/jboss_4_2.dtd">
      
      <jboss>
       <security-domain>java:/jaas/IB-Automation</security-domain>
      </jboss>


      I deploy server-side, start client, and on attempt to invoke any method of any EJB of my app in client's console i see
      EJBAccessException in thread "pool-1-thread-1": Invalid User
       org.jboss.ejb3.security.Ejb3AuthenticationInterceptorv2.invoke(Ejb3AuthenticationInterceptorv2.java:165)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.ejb3.ENCPropagationInterceptor.invoke(ENCPropagationInterceptor.java:41)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.ejb3.asynchronous.AsynchronousInterceptor.invoke(AsynchronousInterceptor.java:106)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.ejb3.BlockContainerShutdownInterceptor.invoke(BlockContainerShutdownInterceptor.java:67)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.aspects.currentinvocation.CurrentInvocationInterceptor.invoke(CurrentInvocationInterceptor.java:67)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.ejb3.stateless.StatelessContainer.dynamicInvoke(StatelessContainer.java:487)
       org.jboss.ejb3.session.InvokableContextClassProxyHack._dynamicInvoke(InvokableContextClassProxyHack.java:53)
       org.jboss.aop.Dispatcher.invoke(Dispatcher.java:91)
       org.jboss.aspects.remoting.AOPRemotingInvocationHandler.invoke(AOPRemotingInvocationHandler.java:82)
       org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
       org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
       org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
       org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
       org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
       org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:206)
       org.jboss.remoting.Client.invoke(Client.java:1708)
       org.jboss.remoting.Client.invoke(Client.java:612)
       org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:60)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
       $Proxy13.invoke(Unknown Source)
       org.jboss.ejb3.proxy.handler.ProxyInvocationHandlerBase.invoke(ProxyInvocationHandlerBase.java:261)
       org.jboss.ejb3.proxy.handler.session.SessionSpecProxyInvocationHandlerBase.invoke(SessionSpecProxyInvocationHandlerBase.java:101)
       $Proxy8.list(Unknown Source)
       cool.ib.client.Controller.listPersons(Controller.java:115)
       cool.ib.client.task.LoadPersonListTask.execute(LoadPersonListTask.java:14)
       cool.ib.client.exec.DescribedTask.run(DescribedTask.java:56)
       java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
       java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
       java.lang.Thread.run(Thread.java:619)
       org.jboss.aspects.remoting.InvokeRemoteInterceptor.invoke(InvokeRemoteInterceptor.java:72)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.aspects.tx.ClientTxPropagationInterceptor.invoke(ClientTxPropagationInterceptor.java:61)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.ejb3.security.client.SecurityClientInterceptor.invoke(SecurityClientInterceptor.java:65)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.ejb3.remoting.IsLocalInterceptor.invoke(IsLocalInterceptor.java:74)
       org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:102)
       org.jboss.aspects.remoting.PojiProxy.invoke(PojiProxy.java:62)
       $Proxy13.invoke(Unknown Source)
       org.jboss.ejb3.proxy.handler.ProxyInvocationHandlerBase.invoke(ProxyInvocationHandlerBase.java:261)
       org.jboss.ejb3.proxy.handler.session.SessionSpecProxyInvocationHandlerBase.invoke(SessionSpecProxyInvocationHandlerBase.java:101)
       $Proxy8.list(Unknown Source)
       cool.ib.client.Controller.listPersons(Controller.java:115)
       cool.ib.client.task.LoadPersonListTask.execute(LoadPersonListTask.java:14)
       cool.ib.client.exec.DescribedTask.run(DescribedTask.java:56)
       java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
       java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
       java.lang.Thread.run(Thread.java:619)
      
      
      WOW!!! It definitely MAY work somewhere!!! Fantastic!!! :D

      Well, couple of times i enjoyed exception claiming that default users and roles .properties files, required for org.jboss.security.auth.spi.UsersRolesLoginModule cannot be found -on invoking EJB's business methods. It might be because the <application-policy name="other">...</application-policy> in the login-config.xml is invoked instead of the policy i've declared?

      So i commented out application-policy name="other", restarted the server and client, but see no difference. The <application-policy name="IB-Automation"> is still being stubbornly ignored by JBoss.

      What should i do to force JBoss 5.0.1 to use the declared application-policy(other than some bugfixing in the project - i am definitely neither JBoss, nor JAAS expert ;) )?

        • 1. Re: JBoss 5.0.1 stubbornly ignores application-policy in log

          Well, have some progress thanks to Wolfgang Knauf's posts:

          For the annotation approach: I know that there are two "SecurityDomain" annotations in the JBoss package: org.jboss.ejb3.annotation.SecurityDomain (the right one) and org.jboss.aspects.security.SecurityDomain (this one does not do anything). Could you check whether you picked the right one?

          Actually there are at least 3 of them. The third one is org.jboss.security.annotation.SecurityDomain ;)

          I replaced annotation with the proper one, and enabled security logging in "server/default/conf/jboss-log4j.xml", as Wolfgang described:

          <appender name="CONSOLE.SECURITY" class="org.apache.log4j.ConsoleAppender">
           <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
           <param name="Target" value="System.out"/>
           <param name="Threshold" value="TRACE"/>
          
           <layout class="org.apache.log4j.PatternLayout">
           <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>
           </layout>
           </appender>
           ...
          
           <category name="org.jboss.security">
           <priority value="TRACE"/>
           <appender-ref ref="CONSOLE.SECURITY"/>
           </category>


          and now i see that username i've hardcoded in client is delivered to server, both "principalsQuery" and "rolesQuery" are executed over datasource and i am experiencing the
          05:23:09,640 TRACE [IB-Automation] Login failure
          javax.security.auth.login.FailedLoginException: No matching username found in Roles

          which i believe i can take care myself. :D
          Hope, this information could help to avoid time wasting.

          • 2. Re: JBoss 5.0.1 stubbornly ignores application-policy in log
            jaikiran

            Wolfgang is right. Annotation packages have changed in AS-4.x to AS-5. For AS5, you can find the guide here http://www.jboss.org/jbossejb3/docs/