7 Replies Latest reply on Nov 30, 2010 3:28 PM by Bill Oberacker

    EBWS Security Support

    Daniel Bevenius Master

      I'm working on "Web service publishing support for ESB services ignores WS-Security. " https://jira.jboss.org/jira/browse/JBESB-2552.

      This task has to concerns:
      1. Add support for container security
      2. Add support for ESB Service security

      1. Add suppport for container security
      Every EBWS in the same jboss-esb.xml will share the same war. Also, any http providers will also share this same war. This brings up the question about how do we configure container security for EBWS since a war can only have a single security domain?

      My question is how do we want to configure the container security for EBWS in this shared war model?
      Should there be a separate global configuration in jboss-esb.xml that defines the security domain that will set the security domain for the war.

      2. Add support for ESB Service security
      Should EBWS be a special case where the normal ESB security is ignored and and we let the container handle security for us. This will make the service unsecured to a stand-alone client using the ServiceInvoker to directly call the service by-passing the gateway (EBWS in this case). But this might be OK?

      What are your thought on this?

      Regards,

      /Daniel

        • 1. Re: EBWS Security Support
          Daniel Bevenius Master

          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

          Downsides:
          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?

          Regards,

          /Daniel

          • 2. Re: EBWS Security Support
            Anil Saldanha Master

            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?

            • 3. Re: EBWS Security Support
              Daniel Bevenius Master

              Hi Anil,

              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?

              Regards,

              /Daniel


              • 4. Re: EBWS Security Support
                Daniel Bevenius Master

                Perhaps this might be a little better:

                Description 'war-security'
                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>
                



                • 5. Re: EBWS Security Support
                  Jeff DeLong Master

                  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.

                  • 6. Re: EBWS Security Support
                    Daniel Bevenius Master

                     

                    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.

                    Regards,

                    /Daniel



                    • 7. Re: EBWS Security Support
                      Bill Oberacker Newbie

                      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:

                       

                      <globals>

                           <war-security method="BASIC" domain="JBossWS"/>

                      </globals>

                       

                       

                      Sorry if this is the wrong place to post this inquiry.

                       

                      Thanks.