JBM 2.0 can be managed by sending management message to a special management address.
Security must be enforced on that address to prevent anybody to send potentially destructive management messages (e.g. delete all queues).
I've added a role in jbm-queues.xml so that only the role "admin" can read/write to this address.
However this breaks the replication mechanism used to replicate management operations through JMX.
When the user invokes a management operation through JMX, it is converted to a core message and sent to the management address using a ClientSession. This core message will be send to both the live node and the backup node ensuring both nodes will handle the management operation.
However the created session does not have any user credentials and it won't work anymore now that only a user with the admin role is allowed to interact with the management address.
For this replication to work, a session must be created with a valid admin user for both the live node and the backup node.
This means:
1. having the same admin user defined on both nodes
2. using this admin user when creating the session used to replicate management message
(1) is obvious since both backup and live nodes are expected to share the same set of users
(2) is less obvious: I could query the security manager until I find a right user (with the admin role) and I'll also have to know its password so that I can create a session with his credential.
The security manager does not expose this information (to avoid any security leak)
So I'm thinking to have the code to create a session inside the security manager (JBMSecurityManagerImpl class). e.g.:
createAdminSession(SessionFactory sf)
{
// find a valid admin user
// use its credentials to create a session from the session factory
// return the admin session
}
This smells like a Bad Idea(TM) but I've no other ideas at the moment to ensure that management operation using JMX are properly replicated.
