anonymous wrote : I am not sure why spend the effort creating a new global section to the jboss-esb.xml. Sorry I might not have done a very good job at explaining this. This issue came up after the addition of the new http-provider. This has the ability to specify a security domain. There is only one war per jboss-esb.xml so this means that this security domain is shared among the all http-providers and all EBWS. To make it clear that this configuration has an effect outside of the http-provider it was decided to create this new global section. anonymous wrote : | In a service oriented architecture each service should be independently deployed, so from a best practice standpoint, I think having a separate jboss-esb.xml file for each service makes more sense. But even with a single service in the esb users might want to have a http-provider (REST) configured and at the same time expose the service as a web service (EBWS). Users might want to configure security for the war that gets generated. Having the configuration in a separate section of jboss-esb.xml hopefully makes it clear that this setting effects the whole war. anonymous wrote : What I would like to understand is that even when authentication is performed by the container, the EBWS gateway will add the security token to the ESB message context, and that the ESB will use this for authorization to ESB services, i.e. rolesAllowed and runAs would be supported. The container/gateway level security is separate from the security at the esb service level. This means that unless there is a Single Sign On solution in place there will be a another authentication when the call reaches the esb service. The esb level security is not affected by this work. Regards, /Daniel View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4257738#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...