[jbossws-dev] Fwd: Project Scope JBWS-3626: globally configure SSL settings for JAX-WS clients.
Alessio Soldano
asoldano at redhat.com
Thu Apr 10 11:27:32 EDT 2014
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
<!-- Draft 1 proposed XML
CXF defines the schema to declare TlsClientParameters via Spring in
the http-conf:conduit element. This schema has copied most but not
all of those elements for TLSClientParametersType. Not all of those
elements are needed for our configuration.
-->
<xs:element name="jbossTlsClientParameters" type="jbossTLSClientParametersType"
minOccurs="0" maxOccurs="1"/>
<xs:complexType name="jbossTLSClientParametersType">
<xs:annotation>
<xs:documentation>
<![CDATA[
A grouping element for 1 or more tlsClientParameters definitions.
]]>
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="tlsClientParameters" type="TLSClientParametersType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="TLSClientParametersType">
<xs:all>
<xs:element name="keyManagers" type="KeyManagersType" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element contains the KeyManagers specification.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="trustManagers" type="TrustManagersType" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element contains the TrustManagers specification.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="cipherSuites" type="CipherSuitesType" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element contains the the CipherSuites that will be supported.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="cipherSuitesFilter" type="FiltersType" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element contains the filters of the supported CipherSuites
that will be supported and used if available.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="secureRandom" type="SecureRandomType" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element contains SecureRandom specification.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="certConstraints" type="CertificateConstraintsType" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element contains the Certificate Constraints specification.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="certAlias" type="xs:string" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element contains the Certificate Alias.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:all>
<xs:attribute name="useHttpsURLConnectionDefaultSslSocketFactory" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies if HttpsURLConnection.defaultSslSocketFactory
should be used to create https connections. If 'true', 'jsseProvider',
'secureSocketProtocol', 'trustManagers', 'keyManagers', 'secureRandom',
'cipherSuites' and 'cipherSuitesFilter' are ignored.
Since 2.2.7.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="useHttpsURLConnectionDefaultHostnameVerifier" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies if HttpsURLConnection.defaultHostnameVerifier
should be used to create https connections. If 'true', 'disableCNCheck'
is ignored.
Since 2.2.7.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="disableCNCheck" type="xs:boolean" default="false">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies if JSSE should omit checking if the
host name specified in the URL matches that of the Common Name
(CN) on the server's certificate. Default is false; this attribute
should not be set to true during production use.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="provider" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the JSSE provider name.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="protocol" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the Protocol Name. Most common
example is "SSL", "TLS" or "TLSv1".
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="sslCacheTimeout" type="xs:int">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the JDK SSL session cache timeout
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="name" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
The endpoint name these settings will be associated with.
A reg-ex expression (e.g., "http://localhost:*") can be used so
the definition can be used for multiple endpoints.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="FiltersType">
<xs:sequence>
<xs:element name="include" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="exclude" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="KeyStoreType">
<xs:annotation>
<xs:documentation>
<![CDATA[
A KeyStoreType represents the information needed to load a collection
of key and certificate material from a desired location.
The "url", "file", and "resource" attributes are intended to be
mutually exclusive, though this assumption is not encoded in schema.
The precedence order observed by the runtime is
1) "file", 2) "resource", and 3) "url".
]]>
</xs:documentation>
</xs:annotation>
<xs:attribute name="type" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies the type of the keystore.
It is highly correlated to the provider. Most common examples
are "jks" "pkcs12".
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="password" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifes the integrity password for the keystore.
This is not the password that unlock keys within the keystore.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="provider" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies the keystore implementation provider.
Most common examples are "SUN".
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="url" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies the URL location of the keystore.
This element should be a properly accessible URL, such as
"http://..." "file:///...", etc. Only one attribute of
"url", "file", or "resource" is allowed.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<!--
<xs:attribute name="file" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies the File location of the keystore.
This element should be a properly accessible file from the
working directory. Only one attribute of
"url", "file", or "resource" is allowed.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="resource" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies the Resource location of the keystore.
This element should be a properly accessible on the classpath.
Only one attribute of
"url", "file", or "resource" is allowed.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
-->
</xs:complexType>
<xs:complexType name="CertStoreType">
<xs:annotation>
<xs:documentation>
<![CDATA[
A CertStoreType represents a catenated sequence of X.509 certificates,
in PEM or DER format.
The "url", "file", and "resource" attributes are intended to be
mutually exclusive, though this assumption is not encoded in schema.
The precedence order observed by the runtime is
1) "file", 2) "resource", and 3) "url".
]]>
</xs:documentation>
</xs:annotation>
<!--
<xs:attribute name="file" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies the File location of the certificate store.
This element should be a properly accessible file from the
working directory. Only one attribute of
"url", "file", or "resource" is allowed.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="resource" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies the Resource location of the certificate store.
This element should be a properly accessible on the classpath.
Only one attribute of
"url", "file", or "resource" is allowed.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
-->
<xs:attribute name="url" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute specifies the URL location of the certificate store.
This element should be a properly accessible URL, such as
"http://..." "file:///...", etc. Only one attribute of
"url", "file", or "resource" is allowed.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>
<xs:complexType name="KeyManagersType">
<xs:annotation>
<xs:documentation>
<![CDATA[
This structure specifies the JSSE based KeyManagers for a single
Keystore.
]]>
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="keyStore" type="KeyStoreType" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element specified the Keystore for these JSSE KeyManagers.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<!--
<xs:attribute name="keyPassword" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the password that unlocks the keys
within the keystore.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="provider" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the KeyManagers provider name.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="factoryAlgorithm" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the algorithm the KeyManagers Factory
will use in creating the KeyManagers from the KeyStore. Most
common examples are "PKIX".
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="ref" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the reference to the KeyManagers bean. This
attribute allows the KeyManagers instance to be constructed by other
means and referenced from this object.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
-->
</xs:complexType>
<xs:complexType name="TrustManagersType">
<xs:annotation>
<xs:documentation>
<![CDATA[
This structure contains the specification of JSSE TrustManagers for
a single Keystore used for trusted certificates.
]]>
</xs:documentation>
</xs:annotation>
<xs:choice>
<xs:element name="keyStore" type="KeyStoreType" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element contains the KeyStore used as a trust store.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="certStore" type="CertStoreType" minOccurs="0">
<xs:annotation>
<xs:documentation>
<![CDATA[
This element contains the CertStore used as a trust store.
]]>
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:choice>
<!--
<xs:attribute name="provider" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the KeyManagers provider name.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="factoryAlgorithm" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the algorithm the KeyManagers Factory
will use in creating the KeyManagers from the KeyStore. Most
common examples are "PKIX".
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="ref" type="xs:string">
<xs:annotation>
<xs:documentation>
<![CDATA[
This attribute contains the reference to the TrustManagers bean. This
attribute allows the TrustManagers instance to be constructed by other
means and referenced from this object.
]]>
</xs:documentation>
</xs:annotation>
</xs:attribute>
-->
</xs:complexType>
<xs:complexType name="CipherSuitesType">
<xs:annotation>
<xs:documentation>
<![CDATA[
This structure holds a list of ciphersuite names that are to be
supported. Note: that does not mean that they will be available.
That depends on the JSSE and Crypto providers.
]]>
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="cipherSuite" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="SecureRandomType">
<xs:annotation>
<xs:documentation>
<![CDATA[
This structure holds the parameters for the Secure Random Number
generator used in the JSSE.
]]>
</xs:documentation>
</xs:annotation>
<xs:attribute name="algorithm"/>
<xs:attribute name="provider"/>
</xs:complexType>
<xs:complexType name="CertificateConstraintsType">
<xs:annotation>
<xs:documentation>
<![CDATA[
This structure holds a list of regular expressions that corresponds to a sequence of
Certificate Constraints on either the Subject or Issuer DN.
]]>
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="SubjectDNConstraints" type="DNConstraintsType" minOccurs="0"/>
<xs:element name="IssuerDNConstraints" type="DNConstraintsType" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="DNConstraintsType">
<xs:annotation>
<xs:documentation>
<![CDATA[
This structure holds a list of regular expressions that corresponds to a sequence of
Certificate Constraints. The optional combinator attribute refers to whether ALL or
ANY of these regular expressions must be satisfied.
]]>
</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:choice>
<xs:element name="RegularExpression" type="xs:string" minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:sequence>
<xs:attribute name="combinator" type="CombinatorType" default="ALL"/>
</xs:complexType>
<xs:simpleType name="CombinatorType">
<xs:annotation>
<xs:documentation>
<![CDATA[
This type refers to whether ALL or ANY of the DNConstraintsType regular expressions
]]>
</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string">
<xs:enumeration value="ANY"/>
<xs:enumeration value="ALL"/>
</xs:restriction>
</xs:simpleType>
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
More information about the jbossws-dev
mailing list