[ https://issues.jboss.org/browse/EJBTHREE-2254?page=com.atlassian.jira.plu... ] Richard Kennard updated EJBTHREE-2254: -------------------------------------- Attachment: RunAsTest.zip JBoss Tools test case attached. Contains source code for EAR and EJB modules. No WAR is required because uses Quartz-based MDBs. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/EJBTHREE-2254?page=com.atlassian.jira.plu... ] Richard Kennard updated EJBTHREE-2254: -------------------------------------- Description: Test case attached. Please open as an Eclispe JBoss Tools project. It creates a Quartz-based MDB that tries to call various other beans (Session, Service and Singleton) that are secured with @RolesAllowed. To allow this, it uses @RunAs. To observe the behaviour: 1. Deploy the app. Notice that the MDB (which triggers every minute) can successfully run the secured methods from the Session bean and the Service bean, but NOT the Singleton bean. The @RunAs credentials are not being passed to the @Singleton bean 2. Uncomment the lines indicated in the code (in RunAsTestMDB.java and jboss.xml). This sets a null security-domain on the Singleton bean, allowing it to be invoked. However immediately afterwards the MDB's @RunAs credentials are lost and it can no longer call the Session bean was: Test case attached. Please open as an Eclispe JBoss Tools project. It creates a Quartz-based MDB that tries to call various other beans (Session, Service and Singleton) that are secured with @RolesAllowed. To allow this, it uses @RunAs. To observe the behaviour: 1. Deploy the app. Notice that the MDB (which triggers every minute) can successfully run the secured methods from the Session bean and the Service bean, but NOT the Singleton bean. The @RunAs credentials are not being passed to the @Singleton bean 2. Uncomment the lines indicated in the code (in RunAsTestMDB.java and jboss.xml). This sets a null security-domain on the Singleton bean, allowing it to be invoked. However immediately afterwards the @RunAs credentials are lost and the MDB can no longer call other beans JBoss Forum Reference: http://community.jboss.org/thread/167591 (was: http://community.jboss.org/thread/167591) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/EJBTHREE-2254?page=com.atlassian.jira.plu... ] henk de boer commented on EJBTHREE-2254: ---------------------------------------- Thanks for the test case. One thing I'm wondering about is the injection of the @Service annotated bean in the MDB. You're using the following code for this: {code} @EJB private IRunAsTestServiceBean mRunAsTestServiceBean; {code} But isn't it impossible to inject such a bean with @EJB? Did you download and run the attached test case to be 100% sure it's the right one? When I run the ear on JBoss AS 6.10, I get the following exception: {code} Caused by: javax.naming.NameNotFoundException: RunAsTestServiceBean not bound at org.jnp.server.NamingServer.getBinding(NamingServer.java:771) [:5.0.5.Final] at org.jnp.server.NamingServer.getBinding(NamingServer.java:779) [:5.0.5.Final] at org.jnp.server.NamingServer.getObject(NamingServer.java:785) [:5.0.5.Final] at org.jnp.server.NamingServer.lookup(NamingServer.java:396) [:5.0.5.Final] at org.jnp.server.NamingServer.lookup(NamingServer.java:399) [:5.0.5.Final] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:728) [:5.0.5.Final] at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:688) [:5.0.5.Final] at javax.naming.InitialContext.lookup(InitialContext.java:392) [:1.6.0_20] at org.jnp.interfaces.NamingContext.resolveLink(NamingContext.java:1350) [:5.0.5.Final] {code} {quote} Note: please change the security-domain defined in jboss.xml to be, say, <security-domain>JBossWS</security-domain> {quote} Why is this needed? It's currently {{avant-ss}}, why would another name be needed? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/EJBTHREE-2254?page=com.atlassian.jira.plu... ] henk de boer commented on EJBTHREE-2254: ---------------------------------------- {quote} Can you please try deploying to JBoss-6.0.0.Final, rather than JBoss-6.1.0.Final? The latter seems to fail for some whole new reason, and I'd rather not complicate things. {quote} Hmmm, besides the @Service issue, the test worked perfectly for me on JBoss AS 6.10. Perhaps you are working on Eclipse 3.6.x/JBoss Tools 3.2? That combination has problems starting JBoss AS 6.10. If you move to JBoss Tools 3.3, you also need to either switch the targeted runtime of the test case projects to "JBoss 6.x Runtime" or rename the runtime to "JBoss 6.0 Runtime". {quote}I don't understand why it would be "impossible to inject such a bean with @EJB"? Where are you getting this from?{quote} Sorry, I simply have no experience with @Service beans and no amount of Googling got me to any documentation on how to inject them. I was just asking if it was impossible, because of the exception I got. It was not a statement ;) {quote}I just retried the test case with a clean JBoss 6.0.0.Final and JBoss Tools and it reproduced the issue for me{quote} With the code in the MDB as follows; {code} mRunAsTestSessionBean.runSecureMethod(); mRunAsTestSingletonBean.runSecureMethod(); // Uncomment the lines in jboss.xml, then uncomment this line too, to see // that calling a singleton bean 'loses' the security domain mRunAsTestSessionBean.runSecureMethod(); {code} But *without* changing jboss.xml, I got the following results: {code} 00:12:00,011 INFO [STDOUT] RunAsTestMDB( "Foo" ): false (expect 'false') 00:12:00,020 INFO [STDOUT] RunAsTestSessionBean.isCallerInRole( "Foo" ): true (expect 'true') 00:12:00,025 INFO [STDOUT] RunAsTestSingletonBean.isCallerInRole( "Foo" ): true (expect 'true') 00:12:00,027 INFO [STDOUT] RunAsTestSessionBean.isCallerInRole( "Foo" ): true (expect 'true') 00:12:00,027 INFO [STDOUT] SUCCESS! {code} So in 6.10 the role does propagate and keeps doing this after the singleton is being called. It's unfortunately a bit late at my place now and I have to call it a day, but I'll check with 6.0 locally tomorrow. Meanwhile, the following might be related to this: http://community.jboss.org/message/637395 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://issues.jboss.org/browse/EJBTHREE-2254?page=com.atlassian.jira.plu... ] henk de boer commented on EJBTHREE-2254: ---------------------------------------- {quote}Could you please let me know how you go reproducing it with JBoss 6.0.0.Final?{quote} That one indeed crashes: {code} INFO [STDOUT] RunAsTestMDB( "Foo" ): false (expect 'false') INFO [STDOUT] RunAsTestSessionBean.isCallerInRole( "Foo" ): true (expect 'true') ERROR [STDERR] java.lang.IllegalArgumentException: Either callerSubject or callerRunAs should be non-null {code} Via Eclipse I deployed the exact same code to both server runtimes. When I start the JBoss AS 6.10, the results are as in my previous comment, when I deploy to AS 6.0 there's the exception as shown above. It thus seems that this issue is fixed by virtue of fixing something else (or the person fixing it forgot to mention it here?) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.jboss.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira