You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Vince Cole <th...@gmail.com> on 2017/04/06 22:19:24 UTC
Unwanted caching of authorization results
It would apoear that org.apache.activemq.security.AuthorizationBroker uses
Security context in some way to cache the results of authorization.
This means if I have a dynamic map (i.e. the permissions could change from
one 'send' request to the next, for any destination) the dynamic nature is
lost due to caching.
Can the caching be disabled or circumvented in any way? I would like the
AuthorizationBroker (or my equivalent of it) to check the map EVERY time.
Thanks
On 6 Apr 2017 04:02, "abhijith" <to...@gmail.com> wrote:
> Hi,
>
> We are using Artemis 1.4.0 version and have a jms topic defined. We have
> defined two specific roles for all topics, one to send and another to
> consume
>
> artemis-roles.properties:
> sendtopic=testtopicuser
> consumetopic=testtopicuser
>
> broker.xml:
> <topic name="exampleTopic"/>
> <security-setting match="jms.topic.#">
> <permission type="consume" roles="consumetopic"/>
> <permission type="send" roles="sendtopic"/>
> </security-setting>
>
> When I try to send to this topic, it works fine. But when I try to consume
> from this topic it fails giving below error. If I add <permission
> type="createNonDurableQueue" roles="consumetopic"/> permission, it works
> fine. Is this a bug in Artemis or am I missing something? Any help is
> greatly appreciated.
>
> javax.jms.JMSSecurityException: AMQ119032: User: testtopicuser does not
> have
> permission='CREATE_NON_DURABLE_QUEUE' on address jms.topic.exampleTopic
>
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelI
> mpl.sendBlocking(ChannelImpl.java:409)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ChannelI
> mpl.sendBlocking(ChannelImpl.java:307)
> at
> org.apache.activemq.artemis.core.protocol.core.impl.ActiveMQ
> SessionContext.createQueue(ActiveMQSessionContext.java:590)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionIm
> pl.internalCreateQueue(ClientSessionImpl.java:1620)
> at
> org.apache.activemq.artemis.core.client.impl.ClientSessionIm
> pl.createTemporaryQueue(ClientSessionImpl.java:314)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQSession.creat
> eConsumer(ActiveMQSession.java:690)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQSession.creat
> eConsumer(ActiveMQSession.java:353)
> at
> org.apache.activemq.artemis.jms.client.ActiveMQSession.creat
> eConsumer(ActiveMQSession.java:325)
> at
> BasicSendReceiveTopicISTest.testBasicSendReceiveForStringMes
> sage(BasicSendReceiveTopicISTest.java:59)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> ssorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.testng.internal.MethodInvocationHelper.invokeMethod(Meth
> odInvocationHelper.java:85)
> at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:816)
> at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:
> 1124)
> at
> org.testng.internal.TestMethodWorker.invokeTestMethods(TestM
> ethodWorker.java:125)
> at org.testng.internal.TestMethodWorker.run(TestMethodWorker.
> java:108)
> at org.testng.TestRunner.privateRun(TestRunner.java:774)
> at org.testng.TestRunner.run(TestRunner.java:624)
> at org.testng.SuiteRunner.runTest(SuiteRunner.java:359)
> at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:354)
> at org.testng.SuiteRunner.privateRun(SuiteRunner.java:312)
> at org.testng.SuiteRunner.run(SuiteRunner.java:261)
> at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java
> :52)
> at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> at org.testng.TestNG.runSuitesSequentially(TestNG.java:1215)
> at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> at org.testng.TestNG.run(TestNG.java:1048)
> at org.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:72)
> at org.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.
> java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce
> ssorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.
> java:147)
> Caused by: ActiveMQSecurityException[errorType=SECURITY_EXCEPTION
> message=AMQ119032: User: testtopicuser does not have
> permission='CREATE_NON_DURABLE_QUEUE' on address jms.topic.exampleTopic]
> ... 37 more
>
>
>
>
>
> --
> View this message in context: http://activemq.2283324.n4.nab
> ble.com/Artemis-Bug-Consume-from-non-durable-jms-topic-tp4724597.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
Re: Unwanted caching of authorization results
Posted by Tim Bain <tb...@alumni.duke.edu>.
Thanks for giving this guidance for anyone who wants to do this in the
future.
If you'd like to have a less hacky (i.e. config file based) way to do this
in a future version of ActiveMQ, please submit an enhancement request in
JIRA. If you do, please copy and paste the workaround you just described so
that anyone on a version before the enhancement is implemented knows how to
use the hacky approach.
Tim
On Apr 7, 2017 3:28 AM, "Vince Cole" <th...@gmail.com> wrote:
OK, so I am answering my own question here (instead of just deleting it all)
in case it might be of help to someone...
I have solved it by doing the following:
* decorate the class SecurityContext
* in the decorator, override method getAuthorizedWriteDests
* in that method, always return an empty map
* ensure that map remains empty (in spite of AuthorizationBroker.send
invoking map.put) by overriding that instance of the map's put method (to
make it do nothing)
* extend AuthorizationBroker
* in the subclass, override method checkSecurityContext
* in that method, instead of returning the SecurityContext, return an
instance of the decorator
Feels a bit hacky o_O
--
View this message in context: http://activemq.2283324.n4.
nabble.com/Unwanted-caching-of-authorization-results-tp4724676p4724707.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Unwanted caching of authorization results
Posted by Vince Cole <th...@gmail.com>.
OK, so I am answering my own question here (instead of just deleting it all)
in case it might be of help to someone...
I have solved it by doing the following:
* decorate the class SecurityContext
* in the decorator, override method getAuthorizedWriteDests
* in that method, always return an empty map
* ensure that map remains empty (in spite of AuthorizationBroker.send
invoking map.put) by overriding that instance of the map's put method (to
make it do nothing)
* extend AuthorizationBroker
* in the subclass, override method checkSecurityContext
* in that method, instead of returning the SecurityContext, return an
instance of the decorator
Feels a bit hacky o_O
--
View this message in context: http://activemq.2283324.n4.nabble.com/Unwanted-caching-of-authorization-results-tp4724676p4724707.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
Re: Unwanted caching of authorization results
Posted by Vince Cole <th...@gmail.com>.
Sorry, forgot to say:
I am using ActiveMQ 5.14.0 and developing my own plugins.
Trying to write a plugin to deliver same functionality as AuthorizationMap,
but as a proper plugin (i.e. using BrokerFilter, etc) so it can read a few
bean properties from activemq.xml on startup.
Also the message from abhijith at the bottom of mine is not related to this,
I replied to it by mistake >.<
--
View this message in context: http://activemq.2283324.n4.nabble.com/Unwanted-caching-of-authorization-results-tp4724676p4724677.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.