I just remove all the invokers except for the JVM invoker. I don't see the type of security you mention to be generically useful enough to incorporate it as it would complicate security pretty dramatically. Besides you'd have to store the user/password for the mail listener locally anyway and if anyone has the abillity to deploy an app then they presumably have the abillity to get at that password. I'm not 100% against it if you can demonstrate it in a non-invasive generically useful way...but this seems like a special requirement and I don't see a great deal of non-perception-only security added by it... Maybe I'm wrong...but I don't see it.
I remember playing with something like this..
The other way around would be to configure the JMS (Destination Mngr)to protected by the same realm as JBCS. This way the user would have an authernticated, and have authorization to publish.
That I partially know( and there was some beer in the conversation) to configure the some realm hierarchy, and make the JMS accept JBCS realm authenticaed users.
In both case I think this would be:
- invasive and complex.
- but still much more elegant than usernames/passwords all over config files.
The main idea is that if you have access to the publish codebase why not use the JAAS that is already there vs trick with semi-secret passwords.
+ password maintance would be really painfull.
I agree that the "username/password" in a config file is intrusive and non-elegant.
I like the idea of disabling the invokers. The only downside is that a system may indeed WANT to have a separate machine publish to a remote queue on the JBCS machine. Disabling the invoker would prevent this. Even so, one may make the argument that if there's going to be 2 servers communicating stuff between them (like, "send this message"), then a web-services interface might be a better service interface than a remote, password-protected queue.
Just in case, though (directed at AronSogor), how would the "JAAS semi-simple" solution work? I was thinking yesterday about the way EJB's have a "runas" annotation, directing the bean to "Run As" a given user role. Is there a way to get MBeans to do something like this, since (for example) the JMSMaillistener is the one submitting to the mail queue.
If the JMS is protected by JAAS (in your semi-simple solution), then what is the mechanism for becoming the role that you want to use when publishing to the queue?
I think you do not want to runas the MBean. There should be context established when the user authenticates via SMTP/POP/IMAP.
Use the users's realm.
How do you access the JAAS user context out of an mBean (e.g., inside of JMSMailListener)?
Aron or Anyone....can you point me in the right direction on this one?
look at the APOP stuff.