Incorporating IceSSL into your application requires installing the plug‑in, configuring it according to your security requirements, and creating SSL endpoints.
Ice supports a generic plug‑in facility that allows extensions (such as IceSSL) to be installed dynamically without changing the application source code. The
Ice.Plugin property (see
Appendix D) provides language-specific information that enables the Ice run time to install a plug‑in.
The executable code for the IceSSL C++ plug‑in 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 plug‑in’s official identifier for configuration purposes, but the IceSSL plug‑in 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 plug‑in. 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 plug‑in’s official identifier for configuration purposes, but the IceSSL plug‑in 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 plug‑in. 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 plug‑in’s official identifier for configuration purposes, but the IceSSL plug‑in 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 plug‑in. As described in
Appendix D, you may also specify the full assembly name instead of the file name in an
Ice.Plugin property.
The IceSSL plug‑in is included in the Ice Touch run time and installed automatically, therefore it is not necessary to explicitly load it. See
Section 41.4.4 for more information on configuring IceSSL in Ice Touch applications.
Installing the IceSSL plug‑in 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 41.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 41.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 41.1 is configured to block external access to TCP port 4063 and to forward connections to port 4064 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.
