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