Another security configuration issue

[gaohoward]

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?

[ataylor]

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.

[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?

[timfox]

I don't think permissions can be inherited or we would have no way of denying any permission in a submatch.

[gaohoward]

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

[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.

[timfox]

"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.

[gaohoward]

Ok, that clears my mind at last. Thanks.

Then my question is gone.