Ice supports a generic plugin facility that allows extensions (such as IceSSL) to be installed dynamically without changing the application source code. The
Ice.Plugin property (see
Appendix C) provides language-specific information that enables the Ice run time to install a plugin.
The executable code for the IceSSL C++ plugin resides in a shared library on Unix and a dynamic link library (DLL) on Windows. The format for the
Ice.Plugin property is shown below:
The last component of the property name (IceSSL) becomes the plugin’s official identifier for configuration purposes, but the IceSSL plugin requires its identifier to be
IceSSL. The property value
IceSSL:createIceSSL is sufficient to allow the Ice run time to locate the IceSSL library (on both Unix and Windows) and initialize the plugin. The only requirement is that the library reside in a directory that appears in the shared library path (
LD_LIBRARY_PATH on most Unix platforms,
PATH on Windows).
The last component of the property name (IceSSL) becomes the plugin’s official identifier for configuration purposes, but the IceSSL plugin requires its identifier to be
IceSSL. The property value
IceSSL.PluginFactory is the name of a class that allows the Ice run time to initialize the plugin. The IceSSL classes are included in
Ice.jar, therefore no additional changes to your
CLASSPATH are necessary.
The last component of the property name (IceSSL) becomes the plugin’s official identifier for configuration purposes, but the IceSSL plugin requires its identifier to be
IceSSL. The property value contains the file name of the IceSSL assembly as well as the name of a class,
IceSSL.PluginFactory, that allows the Ice run time to initialize the plugin. As described in
Appendix C, you may also specify the full assembly name instead of the file name in an
Ice.Plugin property.
Installing the IceSSL plugin enables you to use a new protocol, ssl, in your endpoints. For example, the following endpoint list creates a TCP endpoint, an SSL endpoint, and a UDP endpoint:
As this example demonstrates, it is possible for a UDP endpoint to use the same port number as a TCP or SSL endpoint, because UDP is a different protocol and therefore has its own set of ports. It is not possible for a TCP endpoint and an SSL endpoint to use the same port number, because SSL is essentially a layer over TCP.
Defining an object adapter’s endpoints to use multiple protocols, as shown in the example in
Section 38.3.2, has obvious security implications. If your intent is to use SSL to protect session traffic and/or restrict access to the server, then you should only define SSL endpoints.
There can be situations, however, in which insecure endpoint protocols are advantageous.
Figure 38.1 illustrates an environment in which TCP endpoints are allowed behind the firewall, but external clients are required to use SSL.
The firewall in Figure 38.1 is configured to block external access to TCP port 8000 and to forward connections to port 8001 to the server machine.
One reason for using TCP behind the firewall is that it is more efficient than SSL and requires less administrative work. Of course, this scenario assumes that internal clients can be trusted, which is not true in many environments.
