Hi
Endpoint.publish("https://localhost:9000/foo";, ...);
Endpoint.publish("https://localhost:9000/bar";,...);
when the second publish tries to "reconfigure" the retrieved already configured
JettyHTTPServerEngine
due to the HTTPDestination trying to submit its TLSServerParameters to the
already configured
JettyHTTPServerEngine.
This is an internal detail. A client code calling Endpoint.publish("https://localhost:9000/bar";) has no intention whatsover to
reconfigure the port, its only intention is to register a provider serving a given context. That's it.
With the older version one could just easily set programmatically the port ssl configuration (for port 9000) in this case. And then
have the code registering providers, with no reconfiguration happening and without even knowing anything about ssl.
With your proposal one needs to write this complex expression in addition per
every endpoint registration :
((JettyHTTPDestination)endpoint.getServer().getDestination()).
getJettyHTTPServerEngine().setTLSServerParameters(parms);
Does it mean that for https://localhost:9000/bar one can point to one keystore
for ex and for
https://localhost:9000/foo one can point to another keystore ? What is the
point of calling
setTLSServerParameters(parms); per every endpoint sharing the same port ?
IMHO, from the application's perspective, it's much simplier to just configure a https bean representing the given port once, it's
probably even more portable as it does not depend omn the fact the endpoint may have a server which may have a destination which may
have an engine
IMHO the internal code should only assume the reconfiguration attempt has happend if the request came through the explicit public
api
Thanks, Sergey
Greetings,
As you know there as been some work done to correct/enhance the use of SSL/TLS
in the Http modules. CXF-661, CXF-666, CXF-672.
In that effort, a significant change in the parameters for SSL/TLS was
required. It
added a new
setTLSServerParameters(TLSServerParameters params)
call in which the TLSServerParameters is more in-line with the JSSE, which is
used exclusively for SSL/TLS transports. However, I kept the
setSSLServer(SSLServerPolicy policy)
call in order to maintain and not to break any existing configurations both
Spring and programmatic. Analogous stuff was done for the client side.
However, I have deprecated "setSSLServer()" and everything else internally that
is related
to it. That approach seems to be working. There seem to be some complaints
about the
"deprecation" compiler warnings.
The question is for version 2.0, since we are moving from 1.x, do we want to
eliminate the
old configuration all together? My feeling and some consensus relayed to me is
"yes".
I propose that we do remove the "setSslServer()" and "setSslClient()" calls,
and remove the
"SSLServerPolicy" and "SSLClientPolicy" elements from "security.xsd" .
This will force people to configure SSL/TLS using "TLSServerParameters" and
"TLSClientParameters" elements in "security.xsd" for spring configuration and
"setTLSServerParameters()" and "setTLSClientParameters()" calls for programmatic
configuration..
The next thing in the proposal to take care of the same time, is that there is
an issue about
conflicts in SSL/TLS configuration, which is hard, if not impossible, to
mitigate. This issue is that
there is a setTLSServerParameters() on the AbstractHTTPDestination and also on
the JettyHTTPServerEngine.
The problem is that the JettyHTTPServerEngine can get its TLS configuration
from 2 places.
One being Spring configuration on bean name based on its implementation
"org.apache.cxf.http_jetty.JettyHTTPServerEngine.<port#>"
and the other indirectly by the configuration of the HTTPDestination, because
the destination
also holds a TLSServerParameters property.
This has consequences. The JettyHTTPServerEngineFactory creates
JettyHTTPServerEngine which
basically holds a configured java.net.ServerSocket or SSLServerSocket depending
on whether the TLS configuration is present. The factory also caches these so
that different
HTTPDestinations can be published on the same socket (port number).
This leads to problems in the such as:
Endpoint.publish("https://localhost:9000/foo";, ...);
Endpoint.publish("https://localhost:9000/bar";,...);
when the second publish tries to "reconfigure" the retrieved already configured
JettyHTTPServerEngine
due to the HTTPDestination trying to submit its TLSServerParameters to the
already configured
JettyHTTPServerEngine.
The next item in the proposal is to remove SSL/TLS configuration (both Spring
and programmatic)
from the HTTPDestination all together, and only be able to configure the
SSL/TLS through the
JettyHTTPServerEngine. This is more in line with JSSE as HTTPS, is merely HTTP
over a JSSE
configured Socket.
Several things would need to be done to get this to work well.
Remove the methods
set/getSslServer()
set/getTLSServerParameters
from the AbstractHTTPDesination
and add:
JettyHTTPServerEngine getJettyHttpServerEngine();
to JettyHTTPDestination so that programmatic configuration may happen like so:
EndpointImpl endpoint;
TLSServerParameters parms;
((JettyHTTPDestination)endpoint.getServer().getDestination()).
getJettyHTTPServerEngine().setTLSServerParameters(parms);
So, in summary of this entire proposal is the following:
1. Remove TLS configuration from the AbstractHTTPDestination.
2. Create an API to retrieve the JettyHTTPServerEngine from the
JettyHTTPDestination
3. Remove setSslServer() and setSslClient() from the APIs and remove
SSLServerPolicy
and SSLClientPolicy from the security.xsd.
4. Create a QName sutiable for Spring configuring the JettyHTTPServerEngine
without
using the internal fully qualified class name of its implementation.
I'll be working on this patch this afternoon. So please come up with any
discussion,
complaints, or suggestions (like for the QName Bean name for the
JettyHTTPServerEngine
spring configuration) ASAP.
Thanks,
-Polar
