Mailing-List: contact cxf-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cxf-dev@incubator.apache.org
Received-SPF: pass (herse.apache.org: domain of polar.humenn@iona.com
 designates 65.223.216.181 as permitted sender)
Message-ID: <465DD87F.5090407@iona.com>
Date: Wed, 30 May 2007 16:03:11 -0400
From: Polar Humenn <phumenn@iona.com>
User-Agent: Thunderbird 1.5.0.10 (X11/20070403)
MIME-Version: 1.0
To: cxf-dev@incubator.apache.org
Subject: Re: Http/s configuration Proposal
References: <465D99CA.3000500@iona.com>
 <0ca601c7a2d3$6744f4c0$c301020a@pcgroupiona.com>
In-Reply-To: <0ca601c7a2d3$6744f4c0$c301020a@pcgroupiona.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Sergey Beryozkin wrote:
> 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.

Correct, the desired model, is that the call doesn't have any intention 
of reconfiguring the port, so therefore SSL/TLS configuration 
information is not needed on the HTTPDestination. Enpoint.publish 
creates an
HTTPDestination that may be spring configured or later programmatically 
(re)configured. We eliminate the
conflict with the ServerEngine configuration by removing the SSL/TLS 
configuration information from the
HTTPDestination and just leave it on the JettyHTTPServerEngine.
>
> 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 ? 

No, because the port (read: JettyHTTPServerEngine) is configured with 
the Keystore.

> What is the point of calling
> setTLSServerParameters(parms); per every endpoint sharing the same port ?
>

Right, that is why we get rid of it off the HTTPDestination.

> 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
>

We understand that, and that is what we are working for. Except for 
right now the model violates that
principal.

> IMHO the internal code should only assume the reconfiguration attempt 
> has happend if the request came through the explicit public api

Don't fret, I think the proposed solution gets you what you want.

Cheers,
-Polar

> 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
>>
>