Disabling security on destinations

[starksm64]

How does one disable security on destinations in jbm 1.4? Destinations like the following:

 <mbean code="org.jboss.jms.server.destination.QueueService"
 name="jboss.mq.destination:service=Queue,name=QueueB"
 xmbean-dd="xmdesc/Queue-xmbean.xml">
 <depends optional-attribute-name="ServerPeer">jboss.messaging:service=ServerPeer</depends>
 </mbean>

are picking up the ServerPeer DefaultSecurityConfig. With the old jbossmq this destination would have to security check. This is affecting security tests using mdbs in jbossas trunk currently.

[clebert.suconic]

Scott,

I didn't understand your issue...

Did you mean "with the jbossmq this destination would have *no* security check?

How it was supposed to behave? JBM is just getting the default security from ServerPeer if no destination is provided on QueueService. What testcase is this... and I will be taking a look as I'm messing with upgrading JBM and looking at testcases on 5 now.

[starksm64]

Yes, if there is no security config on the destination, there would be no security check.

The org.jboss.test.security.test.EJBSpecUnitTestCase.testRunAsWithRoles. The mdb's run-as identity is being seen by the jms destination, but there should be no security check.

[clebert.suconic]

Well... this is how it behaves now...

I will need Tim to comment on that.

[timfox]

Ok, I'm trying to understand the requirement here.

Currently if there is no security configuration on the destination the default security will get used.

If instead, there is no security conf on the destination and we drop security altogether, then what do we use the default security for? Does it have any purpose?

(BTW I thought JBoss MQ also fell back to default security if no security was specified - obviously not!)

If you want no security can't you just specify the default security as no security and not specify any security on the dest?

[starksm64]

Removing the default security config has no affect because it appears that a default based on guest is installed anyway:

13:35:04,591 WARN [SecurityMetadataStore] No SecurityMetadadata was available f
or QueueA, adding guest
13:35:04,748 WARN [SecurityMetadataStore] No SecurityMetadadata was available f
or QueueD, adding guest
13:35:04,763 WARN [SecurityMetadataStore] No SecurityMetadadata was available f
or QueueC, adding guest
13:36:32,591 WARN [SecurityMetadataStore] No SecurityMetadadata was available f
or QueueC, adding guest
13:36:32,779 WARN [SecurityMetadataStore] No SecurityMetadadata was available f
or QueueB, adding guest
13:36:34,841 WARN [SecurityMetadataStore] No SecurityMetadadata was available f
or QueueB, adding guest
13:36:34,873 ERROR [RunAsWithRolesMDB] Failed to send reply
javax.jms.JMSSecurityException: User: null is not authorized to write to destination QueueB
 at org.jboss.jms.server.container.SecurityAspect.check(SecurityAspect.ja
va:312)
 at org.jboss.jms.server.container.SecurityAspect.handleSend(SecurityAspe
ct.java:155)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at org.jboss.aop.advice.PerInstanceAdvice.invoke(PerInstanceAdvice.java:
119)
 at org.jboss.jms.server.endpoint.advised.SessionAdvised$send_72806806276
20114891.invokeNext(SessionAdvised$send_7280680627620114891.java)
 at org.jboss.jms.server.endpoint.advised.SessionAdvised.send(SessionAdvi
sed.java)
 at org.jboss.jms.wireformat.SessionSendRequest.serverInvoke(SessionSendR
equest.java:90)
 at org.jboss.jms.server.remoting.JMSServerInvocationHandler.invoke(JMSSe
rverInvocationHandler.java:143)
 at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:771)
 at org.jboss.remoting.transport.local.LocalClientInvoker.invoke(LocalCli
entInvoker.java:101)
 at org.jboss.remoting.Client.invoke(Client.java:1634)
 at org.jboss.remoting.Client.invoke(Client.java:548)
 at org.jboss.remoting.Client.invoke(Client.java:536)

The org.jboss.jms.server.container.SecurityAspect and aop-messaging-server.xml should be part of the integration code, not the jboss-messaging.jar. These depend on SecurityMetadataStore which in turn depends on the security spi of the server. It also depends directly on the org.w3c.dom.Element format of the security config, which makes it unmanagable by the profile service.

Deployment of aspects likewise depends on the target server environment.

This code/configuration needs to be factored out and the appropriate integration projects created for it.