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