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/Se... and in http://www.jboss.org/file-access/default/members/jbossas/freezone/docs/Se... 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/Se... ? 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 ;) )? View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4226299#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...