Been thinking about this and one solution might be to:
1. In the ActionPipelineProcessor we check the actions attribute 'webservice'. If it is true we disable security in the action pipeline and don't perform any security processing. In this case we delegate security to the continer.
2. We add a 'securityDomain' attribute to the service element which would apply only when the 'webservice' attribute is true.
During deployment we use this 'securityDomain' value to set the securityDomain for the war. There is one issue here as mentioned above:
* If there is a http_provider configured it might already have specified a security domain which we will be overriding upon deployment, it might also be
the other way around but the effect is the same. This would throw an exception saying that the authentication domain has already been set.
We would need to document this fact and make sure users understand that there is a single web application for every jboss-esb.xml
1. It might not be obvious by reading the configuration that the same security domain is used by both the http provider and the service
2. Even though you can specify a 'securityDomain' attribute for every service in your jboss-esb.xml they all have to be the same
3. Security can be by-passed by using a ServiceInvoker to call the service directly.
Another option might be to have a global configuration for the security domain that applies to whole jboss-esb.xml. This would then be used for all http providers and all services. This would be a change from what is currently there where you can have different security domains (moduleNames) for different services in your jboss-esb.xml file.
Any thoughts on this?
I guess the Container security kicks in by default at the war level if the security constraints etc exist in web.xml (the same applies to WS deployed as a war).
Probably, you should be looking at ESB security only and selectively introducing a separate security processor in the interceptor chain, based on some configuration?
Kev an I discussed this in a call just a while ago and it was decided to introduce a new top level configuration element.
This element will contain configurations that are global to the jboss-esb.xml file. So we will put the authentication method and authentication domain for the war in this new element.
This is what I'm using at the moment:
<jbossesb xmlns="http://anonsvn.labs.jboss.com/labs/jbossesb/trunk/product/etc/schemas/xml/jbossesb-1.2.0.xsd" parameterReloadSecs="5"> <globals> <auth method="BASIC" domain="JBossWS" /> </globals> ... </jbossesb>
Since the there is one war per jboss-esb.xml (if you have a http-provider or expose a esb service as a web service (EBWS)) it makes sense to have this outside of the http-provider and separate from the esb service security configuration.
Any thought on this? Any better suggestion for the 'globals' element name?
Perhaps this might be a little better:
Security configuration that is global to the jboss-esb.xml file.
These configuration settings are shared for all http-providers and EBWS that are defined in jboss-esb.xml.
<globals> <war-security method="BASIC" domain="JBossWS" /> </globals>
I am not sure why spend the effort creating a new global section to the jboss-esb.xml. I have never thought that there should be more than one "service" per jboss-esb.xml file even though we allow it. 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.
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. Also, that this security context would be available through the API for other programs to access.
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.
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.
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.
So, I've come across this article which seemed to have been the answer to my problem, however, it doesn't seem to work in my implementation.
I have a bunch of services that I've exposed via EBWS (http://domain.com/esb-module/ebws/category/someservice?wsdl), but I am never prompted for a login when adding the "globals" section to my jboss-esb.xml file. I am running ESB 4.8 on my server.
My "globals" looks like:
<war-security method="BASIC" domain="JBossWS"/>
Sorry if this is the wrong place to post this inquiry.