Signed Applet gets AccessControlException calling EJB
I'm trying to use a Signed Applet to invoke a EJB3.0 Stateless Session Bean under JBoss 4.0.3rc1.
I have signed all the .jar files the Applet uses, including jbossall-client.jar, the applet jar, and the jar containing the ejb3 remote interface.
I know my applet has been granted signed permissions, since I can invoke System.getSecurityManager.checkPermission(new RuntimePermission("accessDeclaredMembers")); within the applet without throwing an exception.
I can use a JNDI lookup to find both the JBoss InitialContext and the remote proxy for the bean. (This failed when the applet was unsigned, since I get swapped between 127.0.0.1 and 192.168.x.x as my server IP, but the problem went away after signing).
However, when I actually invoke a remote method on the stub, I get an exception:
java.security.AccessControlException: access denied (java.lang.RuntimePermission accessDeclaredMembers) at java.security.AccessControlContext.checkPermission(Unknown Source) at java.security.AccessController.checkPermission(Unknown Source) at java.lang.SecurityManager.checkPermission(Unknown Source) at java.lang.SecurityManager.checkMemberAccess(Unknown Source) at java.lang.Class.checkMemberAccess(Unknown Source) at java.lang.Class.getDeclaredMethods(Unknown Source) at org.jboss.aop.util.MethodHashing.getInterfaceHashes(MethodHashing.java:135) at org.jboss.aop.util.MethodHashing.calculateHash(MethodHashing.java:204) at org.jboss.ejb3.stateless.StatelessRemoteProxy.invoke(StatelessRemoteProxy.java:61) at $Proxy0.getServerInfo(Unknown Source) at com.cpex.mpv.gui.MpvApplet.getServerInfo(MpvApplet.java:129) at com.cpex.mpv.gui.MpvApplet.init(MpvApplet.java:50) at sun.applet.AppletPanel.run(Unknown Source) at java.lang.Thread.run(Unknown Source)
So where did my permissions go?
Anyone have an idea? Is this just a bug?
My best guess is that the Applet has been given permissions by the AppletClassLoader, which knows that the code came from a signed .jar file. However, the remote proxy class ($Proxy0) may have been created with a different ClassLoader, one that is not paying attention to the signed nature of the jar. Can anyone confirm or deny this guess?