1. Introduction to Security Plugins
Prerequisites |
|
---|---|
Time to complete |
2 hours |
Concepts covered in this document |
|
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 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.
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 RTI 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.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.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.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 theNDDSHOME
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 isC:\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.