1. Introduction to RTI Security Plugins¶

Prerequisites	RTI Connext® DDS installed, including SDK (see the Connext DDS Installation Guide) RTI Security Plugins installed (see the Security Plugins Installation Guide) Familiarity with Connext DDS (i.e., you’ve completed Introduction to Publish/Subscribe) Familiarity with Connext DDS tools, such as RTI Administration Console Familiarity with security concepts and techniques (digital certificates, public key infrastructure, private/public key pairs, authentication, encryption, etc.) Familiarity with defining QoS profiles to Connext DDS applications in XML format
Time to complete	2 hours
Concepts covered in this document	Introduction to DDS Security and RTI Security Plugins Enabling Security Plugins in your Connext DDS applications Dynamic linking against RTI Security Plugins and OpenSSL Translating the security requirements of your system to a Governance file Publishing/Subscribing with different protection kinds (authentication, encryption, etc.) Authenticating your applications with custom digital certificates and private keys Defining privileges for your applications with Permissions files

RTI Security Plugins allow you to address your databus security requirements in a granular and pluggable way. To support this, each of the Security Plugins covers a different aspect of security:

Authentication. Provides the means to verify the identity of the application and/or user that invokes operations on DDS. Includes facilities to perform mutual authentication between DomainParticipants and establish a shared secret.
Access Control. Provides the means to enforce policy decisions on what DDS-related operations an authenticated entity can perform. For example, which Domains it can join, which Topics it can publish or subscribe to, etc.
Cryptography. Implements (or interfaces with libraries that implement) all cryptographic operations including encryption, decryption, hashing, digital signatures, etc. This includes the means to derive keys from a shared secret.
Logging. Supports auditing of all DDS security-relevant events.

The OMG DDS Security specification defines a set of builtin plugins for providing interoperable authentication, access control, cryptography, and a logging Topic. The Security Plugins are the Connext DDS implementation of these OMG DDS Security builtin interoperability plugins. This way, the Security Plugins offer a DDS Security solution that can interoperate with DDS implementations from other vendors.

Figure 1.1 Architecture of an application using Security Plugins. All the currently available security plugins (Authentication, Access Control, Cryptography and Logging) are implemented in a single nddssecurity library.¶

1.1. Key Features¶

The OMG DDS Security specification decouples the different security aspects in a set of plugins:
- Authentication: Ensures that DDS entities are authenticated.
- Access Control: Enforces access control for Domains, Topics, etc.
- Cryptography: Maintains data integrity and confidentiality.
- Logging: Supports auditing of all DDS security-relevant events, allowing you to increase the system’s visibility, which may help track and improve system’s availability.
The Security Plugins can potentially run over any transport, including the builtin UDP transport with multicast and TCP transport.
Secure multicast support enables efficient and scalable distribution of data to many Subscribers.
You can customize the Security Plugins to accommodate proprietary or FIPS 140-2 compliant cryptography solutions, take advantage of custom security hardware or change the behavior of the plugins in any number of ways. The Security Plugins SDK enables you to customize the Security Plugins to meet your system’s security requirements.
The OMG DDS Security specification addresses the security aspect of the communication in a one-to-many, friendly, data-centric way, enabling applications to define different security policies based on the nature of the shared data. This aligns with the decentralized nature of DDS and asserts its benefits:
- No single point of failure
- High performance and scalability
The Security Plugins support all of the cryptographic algorithms specified by the OMG DDS Security specification. For more information about the supported algorithms, refer to Supported Cryptographic Algorithms in the Security Plugins User’s Manual.

1.2. Paths Mentioned in Documentation¶

This documentation refers to the following directories, depending on your operating system:

$NDDSHOME This refers to the installation directory for Connext DDS.

The default installation paths are:
- Non-root user:
  
  /home/<your user name>/rti_connext_dds-<version>
- Root user:
  
  /opt/rti_connext_dds-<version>
$NDDSHOME is an environment variable set to the installation path.

<path to examples> By default, examples are copied into your home directory the first time you run RTI Launcher or any script in $NDDSHOME/bin. This document refers to the location of the copied examples as <path to examples>.

Wherever you see <path to examples>, replace it with the appropriate path.

Default path to the examples:

/home/<your user name>/rti_workspace/<version>/examples

$NDDSHOME This refers to the installation directory for Connext DDS.

The default installation path is:

/Applications/rti_connext_dds-<version>

$NDDSHOME is an environment variable set to the installation path.

<path to examples> By default, examples are copied into your home directory the first time you run RTI Launcher or any script in $NDDSHOME/bin. This document refers to the location of the copied examples as <path to examples>.

Wherever you see <path to examples>, replace it with the appropriate path.

Default path to the examples:

/Users/<your user name>/rti_workspace/<version>/examples

%NDDSHOME% This refers to the installation directory for Connext DDS.

The default installation paths are:
- User without Administrator privileges:
  
  <your home directory>\rti_connext_dds-<version>
- User with Administrator privileges:
  
  "C:\Program Files\rti_connext_dds-<version>"
%NDDSHOME% is an environment variable set to the installation path.

Note

When using a command prompt to enter a command that includes the path C:\Program Files (or any directory name that has a space), enclose the path in quotation marks. For example: “C:\Program Files\rti_connext_dds-<version>\bin\rtilauncher.bat”. Or if you have defined the NDDSHOME environment variable: "%NDDSHOME%\bin\rtilauncher.bat".
<path to examples> By default, examples are copied into your home directory the first time you run RTI Launcher or any script in %NDDSHOME%/bin. This document refers to the location of the copied examples as <path to examples>.

Wherever you see <path to examples>, replace it with the appropriate path.

Default path to the examples:

<your Windows documents folder>\rti_workspace\<version>\examples

Where 'your Windows documents folder' depends on your version of Windows. For example, on Windows 10 systems, the folder is C:\Users\<your user name>\Documents.

Sometimes this documentation uses <NDDSHOME> to refer to the installation path. Whenever you see <NDDSHOME> used in a path, replace it with $NDDSHOME for Linux or macOS, with %NDDSHOME% for Windows, or with your installation path.