From asoldano at redhat.com Thu Apr 10 11:27:32 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Thu, 10 Apr 2014 17:27:32 +0200 Subject: [jbossws-dev] Fwd: Project Scope JBWS-3626: globally configure SSL settings for JAX-WS clients. In-Reply-To: <1135619225.4505063.1397137630129.JavaMail.zimbra@redhat.com> References: <1135619225.4505063.1397137630129.JavaMail.zimbra@redhat.com> Message-ID: <5346B864.3080005@redhat.com> Forwarding Rebecca's message also to jbossws-dev list, which is where this kind dev discussion should probably happen. -------- Original Message -------- Here is an outline of project scope. I'm particularly interested in feedback on the proposed schema for TLSClientParameters. All other comments are welcome as well. Proposal Scope This is an enhancement request JBWS-3626: Ability to globally configure SSL settings for JAX-WS clients to provide a means to define in the webservice subsystem of JBoss server configuration files, (domain.xml and standalone.xml) global configurations for CXF TLSClientParameters objects used by JAX-WS clients. This enhancement is not intended to completely mirror the TLSClientParameters configuration schema defined by CXF in http://cxf.apache.org/schemas/configuration/security.xsd and http://cxf.apache.org/schemas/configuration/http-conf.xsd, but to provide the elements most used by our customers. A subset of the cxf schema deemed appropriate will be used. In an IRC discussion there was a request to provide a xs:choice to reference the "jsse" element of the "securityDomain" and use its keyStore, truststore settings or to provide separate definitions for them. This might be possible but it adds a level of complexity to the implementation. There is not a straight one-to-one mapping between the jsse schema structure and the related cxf schema structure. In addition the "jsse" element does not have a name attribute. The parent element,"securityDomain" does have a name attribute. Accessing the data would require some processing of the "securityDomain" element in order to access the "jsse" element. I would advise against attempting this feature at this time. Areas to be touched CLI/GUI displaying and editing configuration data in accordance with rules of those modules. Serverside parsing and transmission of the TLSClientParameters data to the clientside Clientside processing of the transmitted TLSClientParameters data Addition of appropriate tests to the CLI/GUI, serverside and clientside repositories. Proposed Schema Naming TLSClientParameters The JBoss schema for TLSClientParameter requires a name attribute (see lines 163-173 in the schema) be provided so an appropriate conduit can be created and found. The element name attribute must be the endpoint name as returned above. public final String getConduitName() { endpointInfo.getName() + SC_HTTP_CONDUIT_SUFFIX; The JBoss schema for TLSClientParameter requires a name attribute (see lines 163-173 in the schema) be provided so an appropriate conduit can be created and found. The element name attribute must be the endpoint name as returned above. The name attribute can also be a reg-ex expression (e.g., "http://localhost:*"). This can be used so multiple endpoints can use the conduit. Order of precedence CXF provides 2 means of configuring TLSClientParameters objects. This proposal is adding a third means of defining TLSClientParameters objects via the JBoss server configuration file. The order of precedence must be adjusted accordingly. The order of prescedence will be, A programmatic definition supersedes a Spring configuration definition and a JBoss configuration definition. A Spring definition supersedes a JBoss configuration definition, because it resides in the deployed archive. A JBoss server definition is used when there is no programmatic or Spring definiton. When no programmatic, Spring or JBoss definition is found the system default settings are used, as is currently defined in CXF. Serverside Components There are serverside APIs that support tranferring select server configuration data to the client environment. See org.jboss.wsf.stack.cxf.client.ProviderImpl for a model for how to access elements from the server config and org.jboss.wsf.spi.management.ServerConfig Clientside Components Select server data is already passed to the client. It is recommended the TLSClientParameters data be accesses from org.jboss.wsf.stack.cxf.client.configuration.BeanCustomizer::configureHTTPConduit From asoldano at redhat.com Thu Apr 10 11:38:15 2014 From: asoldano at redhat.com (Alessio Soldano) Date: Thu, 10 Apr 2014 17:38:15 +0200 Subject: [jbossws-dev] Fwd: Project Scope JBWS-3626: globally configure SSL settings for JAX-WS clients. In-Reply-To: <5346B864.3080005@redhat.com> References: <1135619225.4505063.1397137630129.JavaMail.zimbra@redhat.com> <5346B864.3080005@redhat.com> Message-ID: <5346BAE7.2060304@redhat.com> On 10/04/14 17:27, Alessio Soldano wrote: > Serverside Components > There are serverside APIs that support tranferring select server configuration data to the client environment. > See org.jboss.wsf.stack.cxf.client.ProviderImpl for a model for how to access elements from the server config and > org.jboss.wsf.spi.management.ServerConfig > > > Clientside Components > Select server data is already passed to the client. It is recommended the TLSClientParameters data be accesses from > org.jboss.wsf.stack.cxf.client.configuration.BeanCustomizer::configureHTTPConduit Just to clarify, the above mentioned BeanCustomizer is run against any CXF object implementing Configurable whenever CXF calls 'configure' on it. The BeanCustomizer is installed on both client and server CXF Bus instances. When the client bus is actually in-container, the ServerConfig can be retrieved and used to configure the conduits. Speaking of Conduit configuration, I noticed that CXF also has a org.apache.cxf.transport.http.HTTPConduitConfigurer interface; implementors of that interface can be set as extensions to the Bus and are used by the HTTPTransportFactory to configure each conduit being created. So another option for configuring the conduit is to set such a custom HTTPConduitConfigurer implementation in each bus being created whenever the JBossWS integration is active. Alessio -- Alessio Soldano Web Service Lead, JBoss