I have a spring-ws based webapp running witin a Glassfish 3 server. The webapp exposes an MBean with managed operations. Some of these managed operations require authentication and authorization while others support unauthenticated access.
The jvisualvm creates a JMX Connection to my webapp using a URL like this: service:jmx:rmi://localhost/jndi/rmi://localhost:1099/jmxRMIConnector
When making the connection I specify the username and password for security credentials.
During the connection, I verify via debugger that my JMXAuthenticator implementation is indeed called.
My JMXAuthenticator sets a ThreadLocal variable using a comon spring pattern: SecurityContextHolder.getContext().setAuthentication(auth);
to remember the authenticated subject.
When I use jvisualvm's MBean tab to invoke a non-secure managed operation all is well and operation functions as expected.
However, when I use jvisualvm's MBean tab to invoke a secure managed operation the operation seems to be done in different thread than the one that authenticated the connection.
Thus when the secure operation tries to access the subject information from teh ThreadLocal variable using: Authentication auth = SecurityContextHolder.getContext().getAuthentication();
it gets a null value.
Is there some way to always use the same Thread for authenticating the connection as that for invoking operations on the connection?
Please note that I am open to other ways to solve my problem as long as they are portable across web containers.
Thanks for any help.
Does JMX provide an option for a client to authenticate in the same thread as when invoking a managed operation, even if it means authenticating in every managed operation invocation?
That would solve my problem if it is possible. If it is not possible, shall I file an RFE on JMX?
I have solved my own problem based on response here:
It involves using AOP to intercept MBean operation invocations and dealing with authentication token there.