Re: Enhancing HTTP-based connector to support SSL

Hi Simone

This is also the kind of work i've done.
I have also a working SSL implementation for the axis soap based adapter.
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 here is my 
code sample to start soap container with https :

if ( securityProtocol.equals( "https" ) && protocol.equals( "soap" ) ) {
     env.put( MX4JRemoteConstants.ENDPOINT_PROTOCOL, "https" );
     env.put( MX4JRemoteConstants.AXIS_JSSE_SOCKET_FACTORY, 
"org.apache.axis.components.net.SunFakeTrustSocketFactory" );
}
JMXConnectorServer connectorServer = 
JMXConnectorServerFactory.newJMXConnectorServer(url, env, server);
ObjectName cntorServerName = ObjectName.getInstance( 
"Connectors:protocol=" + protocol + ",path=" + path + ",port=" + 
adapterPort );
server.registerMBean( connectorServer, cntorServerName );
connectorServer.start();

the use of this env variable (MX4JRemoteConstants.ENDPOINT_PROTOCOL) to 
define the transport type used is kind of crappy in comparison with your 
solution ( hessian+ssl ).
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..

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

Regards
Bordet, Simone wrote:

>Hi all,
>
>I am enhancing the HTTP-based connectors to support SSL in a simpler
>way.
>
>Right now it is possible to start an external web container and tell
>MX4J to use that instead of starting a new one. This is the only way to
>use SSL.
>
>What I'd like to do is to support JMXServiceURLs like these ones:
>
>service:jmx:hessian+ssl://localhost/hessian
>
>This way, connector servers can be started in SSL mode with little
>support.
>One thing that is not, IMHO, movable into MX4J is the web container
>configuration.
>Right now MX4J support a simple configuration out of the box, that
>simply adds a listener on the JMXServiceURL port.
>However, it is not recommendable to mimic the web container (specific)
>API to support listener configuration such as:
>+ max/min threads
>+ connection timeouts
>+ confidential redirect port
>+ SSL configuration parameters
>+ etc.
>
>So the idea is that, to fine tune the web container, one passes a
>configuration file, that most  web containers can read to self
>configure.
>This is possible passing the property
>MX4JRemoteConstants.HTTP_SERVER_CONFIGURATION in the environment Map.
>
>So, it will be sufficient to pass to MX4J a simple web container
>configuration file with only listeners configured, and MX4J will do the
>rest (deploy servlets, mapping them to JMXServiceURLs and starting the
>web container).
>
>I have already done this:
>+ Refactoring of the ConnectionResolver to support protocols with "+".
>+ Refactoring of class names for soap, hessian and burlap.
>+ Modifications needed to remove hardcoded "http" strings
>
>With these small refactorings, I have hessian+ssl working fine.
>
>Comments welcome.
>
>Simon
>  
>



-------------------------------------------------------
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_id=6595&alloc_id=14396&op=click