RE: Enhancing HTTP-based connector to support SSL

Quoting "Bordet, Simone" <[email protected]>:

> Hi,
>
>> This is also the kind of work i've done.
>
> Great, we're on the same lines.
>
>> I have also a working SSL implementation for the axis soap
>> based adapter.
>
> Same here.
>
>> Basically i had to modify the
>> mx4j.tools.remote.resolver.soap.SOAPResolver class
>> to configure the axis client to deploy the wsdd on an ssl based web
>> container (jetty)
>> and also remove some hardcoded stuff in the HTTPResolver
>> class to make
>> it work.
>>
>> i'm using an env variable MX4JRemoteConstants.ENDPOINT_PROTOCOL to
>> instruct the adapter that it must be running in https
>> and i m passing this var to the JMXConnectorServerFactory
>
> I preferred not to pass this parameter, but to subclass relevant
> classes.
> Basically I have overridden HTTPResolver.getEndpointProtocol(Map) so
> that SSL subclasses return the correct protocol.
> This result in more classes (although very simple), but less work for
> the user.
> That's why I preferred this way.

I agree your solution is the best one.

>> The MX4JRemoteConstants.AXIS_JSSE_SOCKET_FACTORY constant is used to
>> configure the axis client ssl socket factory to use a fake
>> trust manager
>> so that the axis client does not crash during sslhandshake when
>> deploying the wsdd, maybe that this stuff could be harcoded in the
>> SOAPResolver since we do not need
>> to really trust the webcontainer nor much flexibility..
>
> I haven't had any need to introduce this class.
> Can you please expand on the problems you had ?

The problems occurs with the Axis adminclient when connecting to the
webcontainer to deploy the wssd. By default the admin client needs to trust
the webcontainer certificate, so if the web container certificate is self
signed and not included in the client trust store we have an issue.
This is what was happening for me.
I have no room in my application to set the generic ssl system properties s
uch
as "javax.net.ssl.trustStore" to fix the issue and i did not wanted
to add the web container self signed certificate to axis client trust store
(I find this not really clean..)

The solution was to modify the SOAPResolver code calling the axis client to
instruct the axis client to use an fake trust manager who accepts any 
certifs..

There is another issue when the webcontainer is configured to require clien
t
certificates. Unless you set some javax.net.ssl.* system property by defaul
t
the axis client is not configured to send certificate.

For me, the best solution would be to not always rely on 
javax.net.ssl.* System
properties, and also add the possibility to provide a custom SSLContext obj
ect
to the mx4j SOAPResolver class. The axis client uses the
org.apache.axis.components.net.SecureSocketFactory interface to create its
internal SSL context, and mx4j class implementation who would
simply return the passed in SSL context object could make it work.

The mx4 class would have to extend the
org.apache.axis.components.net.JSSESocketFactory and simply override the
initFactory method to create an sslSocketFactory with the provided SSLConte
xt.

I hope it was clear :o))

>
> Have you set this system property ?
> System.setProperty("javax.net.ssl.trustStore", "<keystore>");
>
> In client.wsdd, did you change the <transport name="http" ...> into
> <transport name="https" ...> ? I did not, and it seems to work fine.

I tried this too but it had no effect.

>> Another remark, maybe that the Connectors protocol name should also
>> include tls support which would give :
>>
>> hessian+ssl
>> hessian+tls
>> burlap+ssl
>> burlap+tls
>> soap+ssl
>> soap+tls
>
> This would be trivial to add, but since there is no difference between
> TLS and SSLv3, well...
> For example, in Jetty I could not find any way to specify the SSL
> algorihtm: what is passed to SSLContext.getInstance(<algorithm>) ?

Well java impl makes no difference unfortunatly.. but the sslv3 and tls
ciphers list is not the same.. anyway that's another story :O)

> My implementation result in this code to start a connector over SSL:
>
> System.setProperty("javax.net.ssl.trustStore", "simon.keystore");
> Map serverEnv = new HashMap();
> serverEnv.put(MX4JRemoteConstants.HTTP_SERVER_CONFIGURATION,
> "mx4j.https.xml");
> JMXServiceURL url = new JMXServiceURL("hessian+ssl", null, 8443,
> "/hessianjmx");
> JMXConnectorServer cntorServer =
> JMXConnectorServerFactory.newJMXConnectorServer(url, serverEnv,
> newMBeanServer());
> cntorServer.start();
>
> The external parts are the "mx4j.https.xml" Jetty configuration file,
> which contains the listener on port 8443, and the keystore.
> The system property is needed to trust the self-signed certificate. If
> this is imported into cacerts, or it is signed by a trusted entity, it
> is not needed.
>
> As I've told, I prefer to leave the listeners (or <Connector> in Tomcat
> lingo) out of MX4J.
> Configuring a listener in Jetty has 9 parameters (from the example
> configuration), and same for Tomcat.
> While there may be the possibility to find sensible defaults, I would
> leave that to the next iterations, unless proven extremely simple to
> add.

The solution i have concerning the webcontainer config "issue" is to 
build via a
simple custom API a complete config file for jetty with one http or https
listener. Save the xml file on hard disk and then instruct mx4j with the
MX4JRemoteConstants.HTTP_SERVER_CONFIGURATION env param to use the
freshly built config file.

Maybe that a very simple interface could be added to MX4j to build 
config files
with basic implementation for jetty or tomcat..
The params are always the same for every servers configs.. http listener po
rt,
keystore, truststore, keystore password.... With such config builders, 
devs who
are not familiar with jetty or tomcat config files can quickly 
configure the web
container. This solution is also flexible since the web container can still
 be
configured by hand since it still uses the
MX4JRemoteConstants.HTTP_SERVER_CONFIGURATION during webcontainer startup.

Ohh BTW i'm on the dev maling list since a long time, no need to send
the mail to [email protected] for your replies.

Merci et bonne fin de journée.

SuperBonBon

> Thanks,
>
> Simon
>



----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click