problems using secured remote EJB interface to Profile Servi

[ips]

https://jira.jboss.org/jira/browse/JOPR-263 is preventing us from using the secured remote EJB interface from the jbas5 plugin running within an Enterprise Jopr Agent. Note, we are able to use the non-secured non-EJB remote interface without any issues, but this doesn't do us much good, since this interface will be disabled in EAP5 anyway.

The issue stems from the following existing code in the EMS library (a JMX client library, which is used by the jbas5 plugin for remote JMX calls), which was added as a workaround for https://jira.jboss.org/jira/browse/JOPR-9:

SecurityAssociation.clear();
 SecurityAssociation.setPrincipal(new SimplePrincipal(principal));
 SecurityAssociation.setCredential(credential);

This code is called every time a JMX invocation is made via EMS, in order to ensure the principal and credential, which are stored in ThreadLocals, have the correct values for the current thread. This is necessary, since a single Jopr Agent can be used to manage multiple JBAS instances, each with different JNP usernames/passwords. The problem is that the above code appears to have the side effect of resetting the JBoss-Security SecurityContext for the current thread to null, which causes subsequent calls to the EJB Profile Service proxies to fail with "javax.ejb.EJBAccessException: Caller unauthorized" exceptions.

I've written a simple test client that demonstrates the issue:

https://svn.jboss.org/repos/jopr/trunk/etc/jbas5-ejb-client/

How can we fix JOPR-263 without reintroducing JOPR-9?

Thanks,
Ian

[starksm64]

We should be using a better api than the SecurityAssociation to start with. Anil would have to comment on whether the SecurityAssociation should still be backwards compatible, but a JAAS login is the guaranteed supported api. I did raise an issue about the ejb3 client security interceptor not creating a valid SecurityContext from the information passed in by one of the client jaas login modules.

Also, we discussed dropping the ejb3 facade and just introducing a secured remote proxy to reduce the dependencies an admin client has to have.

[anil.saldhana]

I have tried to maintain the backwards compatibility with SecurityAssociation. But there are few cases such as vmwide association of context that seems to be broken.

Irrespective, the recommended usage on the client side is the SecurityClient.

Example: http://www.jboss.org/file-access/default/members/jbossejb3/freezone/docs/tutorial/1.0.7/html/Security_and_Transactions_in_EJB3.html

[ips]

Here's links to the code from EMS I mentioned in my original post:

https://mc4j.svn.sourceforge.net/svnroot/mc4j/trunk/mc4j/modules/ems/src/ems-impl/org/mc4j/ems/impl/jmx/connection/support/providers/proxy/GenericMBeanServerProxy.java

(line 118)

https://mc4j.svn.sourceforge.net/svnroot/mc4j/trunk/mc4j/modules/ems/src/ems-impl/org/mc4j/ems/impl/jmx/connection/support/providers/JBossConnectionProvider.java

(line 240)