7 Replies Latest reply on Apr 30, 2009 10:15 AM by gaohoward

Another security configuration issue

gaohoward Apr 29, 2009 11:57 PM

Suppose we have the following permission config

 <!-- any user can have full control of generic topics -->
 <security match="jms.topic.#">
 <permission type="createDurableQueue" roles="user"/>
 <permission type="deleteDurableQueue" roles="user"/>
 <permission type="createTempQueue" roles="user"/>
 <permission type="deleteTempQueue" roles="user"/>
 <permission type="send" roles="user"/>
 <permission type="consume" roles="user"/>
 </security>

 <security match="jms.topic.news.europe.#">
 <permission type="send" roles="europe-user"/>
 <permission type="consume" roles="news-user"/>
 </security>

 <security match="jms.topic.news.us.#">
 <permission type="send" roles="us-user"/>
 <permission type="consume" roles="news-user"/>
 </security>

There are three security 'match'es. The last two have all 'create*' and 'delete*' permissions omitted. In that case, I assume that the 'create*' and 'delete*' permission settings for 'jms.topic.news.us.#' and 'jms.topic.news.europe.#' should be inherited from 'jms.topic.#'. But test shows that there is no such inheritance exists. Is it so designed?

1. Re: Another security configuration issue

ataylor Apr 30, 2009 12:42 AM (in response to gaohoward)

The match won't inherit the permissions, but if the address being checked matches jms.topic.# and the user has that role then it will be granted.
Actions
2. Re: Another security configuration issue

gaohoward Apr 30, 2009 12:57 AM (in response to gaohoward)

Hi Andy, in that case if a user has both 'user' role and 'europe-user' role, he is still not allowed to send messages to topics like jms.topic.news.europe.europeTopic?
Actions
3. Re: Another security configuration issue

timfox Apr 30, 2009 1:11 AM (in response to gaohoward)

I don't think permissions can be inherited or we would have no way of denying any permission in a submatch.
Actions
4. Re: Another security configuration issue

gaohoward Apr 30, 2009 1:40 AM (in response to gaohoward)

ok, 'inherit' may not be the right word. :)
Actions

5. Re: Another security configuration issue

gaohoward Apr 30, 2009 8:19 AM (in response to gaohoward)

Hi Andy, here I rephrase my thought.

Actuall it is about how the SecurityDeployer works with wild cards. Again let's take this config:

 <security match="jms.topic.#">
 <permission type="createDurableQueue" roles="user"/>
 <permission type="deleteDurableQueue" roles="user"/>
 <permission type="createTempQueue" roles="user"/>
 <permission type="deleteTempQueue" roles="user"/>
 <permission type="send" roles="user"/>
 <permission type="consume" roles="user"/>
 </security>

 <security match="jms.topic.news.europe.#">
 <permission type="send" roles="europe-user"/>
 <permission type="consume" roles="news-user"/>
 </security>

 <security match="jms.topic.news.us.#">
 <permission type="send" roles="us-user"/>
 <permission type="consume" roles="news-user"/>
 </security>

Here we have three security elements. There match strings are

jms.topic.#
jms.topic.news.europe.#
jms.topic.news.us.#

Suppose we deploy the above config into SecurityDeployer. Given a topic whose address is 'jms.topic.news.europe.europeTopic', what if we call

HashSet roles = SecurityDeployer.securityRepository.getMatch('jms.topic.news.europe.europeTopic');

What's interesting is that 'jms.topic.news.europe.europeTopic' matches both 'jms.topic.#' and 'jms.topic.news.europe.#'. So I expect
that it will return three roles: user, europe-user and news-user. But it actually returns 2 - europe-user and news-user.

6. Re: Another security configuration issue

timfox Apr 30, 2009 8:24 AM (in response to gaohoward)

"gaohoward" What's interesting is that 'jms.topic.news.europe.europeTopic' matches both 'jms.topic.#' and 'jms.topic.news.europe.#'. So I expect that it will return three roles: user, europe-user and news-user. But it actually returns 2 - europe-user and news-user. [/quote wrote:

Returning just europe-user and news-user would be correct.

Security settings are not inherited. I.e. the more specific matching set of permissions should take precedence.

We need it that way otherwise we wouldn't be able to deny any roles on a more specific match, like I mentioned in my previous post.
Actions
7. Re: Another security configuration issue

gaohoward Apr 30, 2009 10:15 AM (in response to gaohoward)

Ok, that clears my mind at last. Thanks.

Then my question is gone.
Actions

Go to original post