[jboss-dev-forums] [Design of Messaging on JBoss (Messaging/JBoss)] - Re: Disabling security on destinations

scott.stark@jboss.org do-not-reply at jboss.com
Sat Dec 8 16:48:05 EST 2007


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.


View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4111403#4111403

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4111403



More information about the jboss-dev-forums mailing list