-
1. Re: JMS Security permissions clarification
adrian.brock Aug 16, 2005 10:44 AM (in response to timfox)Yes, the JBossMQ roles take the set of all operations and groups them
according to the read/write/create permissions.
It leaves the user to map roles to these permissions.
You could make the permissions more configurable at the cost of more
complexity and potentially security problems if somebody does it wrong.
e.g. allowing readers to create durable subscriptions by mistake.
It is not necessarily per destination. If the destination has no roles, it uses the
default security from the security manager.
http://wiki.jboss.org/wiki/Wiki.jsp?page=ConfigJBossMQSecurity
http://wiki.jboss.org/wiki/Wiki.jsp?page=SecurityConf -
2. Re: JMS Security permissions clarification
ovidiu.feodorov Aug 16, 2005 12:22 PM (in response to timfox)In particular that create on a destination doesn't refer to the creation of a destination but to the creation/destruction of durable subscriptions on that destination.
Yes this is correct. Creation of destination means deployment of the destination. This is DestinationManager's responsibility. It is an "administrative" operation, which is either performed by a deployer or explicitely via a JMX operation. Securing it is equivalent with securing the JMX operation.If so, do you think we should consider renaming the permissions from read-write-create to, say, receive-send-administer_durable, (or similar) so that we are more explicit about this?
I don't know. Adrian, do you know of any complaints about the current convention? -
3. Re: JMS Security permissions clarification
adrian.brock Aug 16, 2005 12:30 PM (in response to timfox)"ovidiu.feodorov@jboss.com" wrote:
I don't know. Adrian, do you know of any complaints about the current convention?
You mean other than people don't read the documentation? :-) -
4. Re: JMS Security permissions clarification
ovidiu.feodorov Aug 16, 2005 12:34 PM (in response to timfox)No, I mean that people who read documetation say: "This is confusing, it shouldn't be called 'create' but 'create_durable_subscription', because I shouldn't be required to read documentation to understand a configuration file"
-
5. Re: JMS Security permissions clarification
adrian.brock Aug 16, 2005 12:36 PM (in response to timfox)Like I said on the other thread, there should be as little code in
JBoss Messaging as possible. It should reuse what JBoss already has.
If somebody wants to go beyond simple role based security this should be possible
and hopefully relatively easy...
e.g.
* authority based on message size
* authority based on number of message sends/throughput
* augmenting the "message selector" with an authorization
e.g. is the user allowed to receive this message?
* your usecase here
But we don't have to provide these implementations (at least in the initial release).
Just make it possible. -
6. Re: JMS Security permissions clarification
adrian.brock Aug 16, 2005 12:40 PM (in response to timfox)"ovidiu.feodorov@jboss.com" wrote:
because I shouldn't be required to read documentation to understand a configuration file"
That approach just leads to people making random configurations
based on what they think it means. You'll never get a name that truly describes
what it does unless it is ridicously long. And people never read comments
attached to the xml.
You'll be surprised how many questions in the forums are based on people
"feeling the need" to play with configuration they don't understand.whether-users-in-this-role-can-create-durable-subscriptions-they-must-also-have-read-permission=true
-
7. Re: JMS Security permissions clarification
ovidiu.feodorov Aug 16, 2005 12:45 PM (in response to timfox):)
Fair enough. Let's call them r/w/c then :) -
8. Re: JMS Security permissions clarification
adrian.brock Aug 16, 2005 12:57 PM (in response to timfox)Obviously it is a balance.
I remember an old piece of research that said variable names you should ideally be
13 characters long. (Probably by some IBM consultant :-)
Anything less is not meaningful
Anything longer is too hard to type. Or too easy to mistype.
Of course, if you actually apply that rule, you find it doesn't work.
It depends on the usecase.