| Previous: Tutorial: Distributed computing - How to use MIRA across different processes in a network |
|---|
Prerequisites
This tutorial assumes that you know how to create configuration files that are launched in a distributed way using multiple Frameworks.
Introduction
Normally, a framework that acts as a server accepts any incoming connection from remote client Frameworks. In most cases this will be acceptable. But there will be cases where a single Framework should be protected and where only authorized Frameworks can connect to:
- In a science lab where one wants to run tests that should not be interrupted or interfered by other Frameworks in the same network
- In a customer application that runs in a publicly accessible network
In this tutorial, we will learn how to use secure connections between Frameworks and how to protect your Frameworks from being accessible by other unauthorized ones.
There exist three levels of protection. The different levels can be enabled via command line parameters or in a configuration file. In the following we describe each level and give an example how to enable the level via the command line and via configuration file.
| These security measures are designed to protect the network aspect of the frameworks. All security levels and mechanisms rely on the fact that the systems running the application are protected from malicious access. If there is public access to the system, one can easily fetch the used groups, passwords or RSA keys. |
Level 1 - Work groups
Each Framework can belong to a work group. Only Frameworks within the same work group are allowed to connect to each other. This is the weakest form of security. To start a Framework that belongs to a work group, just specify the –auth-group command line parameter when starting mira, miragui or miracenter.
We use the PublisherProcess.xml configuration file from the Tutorial: Distributed computing - How to use MIRA across different processes in a network tutorial.
It contains an int publishing unit and sets the port for listening for incoming connections to 1234. The following line starts a Framework that launches the given configuration file and will only allow Frameworks to connect that belong to the group "MyGroup".
Alternatively, one can modify the configuration file as follows to specify the group in there.
If you try and connect to this framework without setting the same group you will get the following error.
Level 2 - Passwords
A more secure protection is the use of passwords. Whereby the sole use of passwords adds no additional security. Passwords should be combined with work groups. The following example launches again a Framework using the int publisher configuration but this time it additionally uses password protection.
Alternatively, the password can be specified in the configuration file.
Now only remote Frameworks are allowed to connect that use the same group and password. If you only get the group right, you will get the following error when trying to connect to the Framework.
Level 3 - Strong authentication using RSA keys
The use of passwords adds enough security in most cases. But password - group combinations form only weak authentication. Whenever strong authentication is needed, one can use RSA keys. RSA security can - like passwords - be combined with the use of groups for even stronger authentication.
First we need a file that contains a private RSA key. The MIRA installation provides a tool for generating RSA key files. It is called "miraauth". The following command will generate a key file MyKey.key that contains a private key only and that will be used in the next examples.
All Frameworks that like to connect to each other must now share the same private key (key file). On connection, both sides will generate and sign messages that are sent to the remote side where the message is verified. If verification succeeds, authentication is complete. To enable RSA security just pass the key file as command line parameter:
Alternatively, the used keyfile can be specified in the configuration file.
