The HTTP MTP is directly included in the JADE distribution and is activated by default on Main Containers. As usual for MTPs it is possible to activate it on peripheral containers too by means of the -mtps option (look at the JADE Administrator's guide for details).
This document describes how to configure it to tune its behaviour according
to the application requirements (e.g. performances) and the environment characteristics
(e.g. firewalls and proxies). Such configurations can be specified by means of
typical JADE command line options in the form -<key> <value> or,
in case the -conf <properties file> option is used, by means of properties in the form
key=value
jade_http_mtp_numKeepAlive=n
This parameter allows specifying the maximum number of connections that the mtp is allowed to keep. Default value for this parameter is 10. A value of 0 means that the connection reusage mechanism is turned off.
jade_http_mtp_timeout=milliseconds
The Server part of the HTTP MTP also keeps alive connections from other platforms that are using the connection reusage feature. By setting up this timeout we can set a maximum idle time for these connections in order to improve the memory consumption. Default value for this parameter is 60000 (1 minute). If we want this time to be infinite we must put this value to 0.
jade_http_mtp_outPort=nThis parameter allows specifying the local port used by outgoing connections with remote platforms. If this parameter is not specified, a random free port will be used.
jade_http_mtp_proxyHost=hostNameSetting up these parameters we can use a HTTP Proxy to redirect the platform outgoing messages. If these parameters are not specified, then connections will be opened directly to the remote platforms.
jade_http_mtp_parser=saxClassNameThe HTTP MTP needs a SAX XML Parser. By means of this parameter it is possible to specify the SAX parser implementation class (fully qualified class name). Such class must be in the classpath. If this parameter is not specified the default SAX parser included in the underlying JDK is used.
This HTTP MTP includes support for HTTPS, that means HTTP over SSL connections. This functionality basically permits having a secure and authenticated channel between platforms using this MTP.
How it works ? Basically when a connection is being established between two platforms, the platform acting as server (receiver), sends its Certificate to the platform that acts as client (sender). At this moment, the client side must decide if this certificate is trusted. Optionally, the server can request the client to be authenticated. If this occurs, client must send its certificate to the server and makes also its own trust decision from the received certificate. At this point, if both parts agree in having a secure communication (because they trust each other), they exchange a session key, that will be used to encrypt all data sent through the network.
What we gain in using HTTPS? We gain in security. Using SSL in communications we are sure that nobody can spy data sent through the network. If we are doing trust decisions properly, we are also sure that messages are sent to the correct platform. If we force client authentication, we can also assure that platforms sending messages to our platform are trusted platforms.
What we loose ? Obviously we loose in performance. HTTPS MTP is approximately 15% slower than normal HTTP MTP.
HTTPS MTP configuration is not easy as with HTTP MTP. It requires to understand some basic concepts that will be exposed in the following lines.
As we said in the previous section using SSL connections implies using certificates to authenticate platforms. It implies also making decisions when a certificate from a remote platform is received. All those things are done automatically by this MTP but we must specify where this certificates are, and which trust decisions are made when remote certificates are received.
The first step in order to use HTTPS MTP is creating our platform's certificate. We can solve this step by using java keytool. This program is provided with Java SDK and JRE platforms. If we don't have a certificate signed by a Certification Authority, we can create our own self-signed certificate by using the following command:
After this step we have a java Keystore (file named keyfile) that contains our platform's certificate and private key. This information is protected with the password mypassword.
The sending of certificates during the handshaking process of the protocol is done automatically. Key Managers are responsible to locate the certificate and private key of the platform when are needed by HTTPS. The default KeyManager searches for keys and certificates inside a Java Keystore file. There are two mandatory arguments for default keymanager: location of our platform's Java Keystore file and password for accessing key material inside this file. The name of the parameters can be specified from the command line:
Or putting them inside a jade configuration file
As we said in the introduction, an HTTPS client must perform some trust decisions. More precisely, when a server certificate is received it must be decided weather this certificate is trusted or not. In case the certificate is not trusted, the connection will be aborted. This trust decision is done automatically by HTTPS MTP and we provide 3 different behaviours for performing trust decisions:
As we said previously, we can force authentication from the server side. This means that we are forcing all platforms trying to send messages to our platform to be authenticated. This issue can help us to restrict the set of platforms being able to send messages to us. To enable this feature you only need to set the following parameter:
HTTPS MTP is included within the HTTP MTP so it is not really another MTP. The behaviour of this MTP is working without secure communications by default. If we want the MTP running with secure connections, we must initialise it by setting a transport address beginning with "https". This will be detectedat the beginning and security connections will be used. Of course, using security connections implies setting also required configuration parameters as we said previously.
Example starting HTTP MTP with HTTPS support:For all the cases explained here we need platform certificate and private key. We will suppose that we have created a self signed-certificate for our platform:
keytool -genkey -alias myplatform -keystore mykeys.ksAfter this file is created we will show some jade configuration files, exploiting all HTTPS MTP different behaviours: