3.2. RTI Security Plugins

This release of Security Plugins uses OpenSSL 1.0.2o. (Release 5.3.1 used OpenSSL 1.0.2n.)

Note: OpenSSL 1.0.2o fixes moderate severity vulnerabilities (RTI Issue ID PLATFORMS-1642), so it is recommended that you upgrade the version of OpenSSL that you are using to this one. For instructions on installing the latest version of OpenSSL, see the RTI Security Plugins Getting Started Guide.

The following issues affect backward compatibility in RTI Security Plugins.

3.2.1. Configuration Changed Authentication and Access Control property names

Starting with this release, you may use the property names that are in the DDS Security specification for configuring some attributes of the builtin Authentication and Access Control Plugins. See the section “Updated configuration property names” in the RTI Security Plugins Release Notes for a list of properties.


  • The values of these properties require a prefix, which may be either file: or data:,.
  • If both the legacy and new properties are specified for a given attribute, the new property is applied, and the legacy property is ignored.
  • The legacy com.rti.serv properties are not equivalent to the new dds.sec properties with respect to the inherit attribute of the <property> tag in a QoS profile. For example, if profile “Base” specifies <name>dds.sec.auth.identity_ca</name> <value>CaBase</value> and profile “Derived” (which has base_name="Base") specifies <name>com.rti.serv.secure.authentication.ca_file</name> <value>CaDerived</value>, the CA will end up being “CaBase” because the two properties have different names, and the new property takes precedence over the old one.

To avoid confusion, it is recommended to update your property names to match those in the DDS Security specification and to add the file: prefix to the corresponding property values. The com.rti.serv.secure prefix should be used only for RTI-specific property names. See the Authentication chapter of the Security Plugins Getting Started Guide for more information on these properties. Changed default Persistence Service “dds.data_writer.history.key_material_key”

The undisclosed non-NULL default dds.data_writer.history.key_material_key has changed. As a result, Persistence Service databases protected with the old default key will not be accessible by the new Persistence Service. Note that using the default key is discouraged, and you should set dds.data_writer.history.key_material_key to a value other than the default.

If you need to access a Persistence Service database encrypted with the old default key using a new version of Persistence Service, please contact RTI Support at support@rti.com. Changed Persistence Service encryption algorithm

The algorithm used to encrypt a Persistence Service database has changed to be more secure. As a result, databases protected with the old Persistence Service will not be accessible by the new Persistence Service. Changed matching behavior of allowed partitions condition

The DDS Security specification describes the matching behavior of the <partitions> section within an <allow_rule> of a Permissions file. In order for a DataWriter or DataReader to be matched with an “allowed partitions” condition, the DDS entity’s partitions must be a subset of the partitions in the condition. This release enforces this matching rule.

To change this enforcement, you may set the security plugin property access_control.use_530_partitions to TRUE. If TRUE, then a DataWriter or DataReader will be matched with an “allowed partitions” condition as long as at least one of the DDS entity’s partitions matches one of the partitions in the condition; this is consistent with Connext DDS 5.3.0 behavior. If FALSE, then the entity’s partitions must be a subset of the condition’s partitions; this is consistent with the behavior of the DDS Security specification. The default value is FALSE.

Here’s an example:

Table 3.4 Allowed Partitions Condition Example
DataWriter Partitions Allowed Partitions Condition use_530_partitions allowed?
[A, B] [B, C] TRUE yes, because B is in [B, C]
[A, B] [B, C] FALSE no, because A is not in [B, C] Change to mutability of Publisher PartitionQosPolicy

The Publisher PartitionQosPolicy always used to be mutable. Now, it is immutable if the Publisher contains any DataWriter that meets both of the following two criteria:

  • The TopicSecurityAttributes for that DataWriter have is_read_protected (which corresponds to <enable_read_access_control> in the Governance Document) set to TRUE.
  • The DataWriter has the DurabilityQosPolicy kind set to something other than VOLATILE. New protection for Builtin Logging Topic

This release changes the Governance XML setting metadata_protection_kind from NONE to SIGN for the Builtin Logging Topic. This change was made to be compliant with the DDS Security specification. It breaks configuration compatibility between this and previous releases when using a DataReader to subscribe to the Builtin Logging Topic. The DataReader must now be configured to use metadata_protection_kind = SIGN.

To change this behavior, you may set the security plugin property access_control.use_530_logging_protection to TRUE. If TRUE, then the metadata_protection_kind will be NONE for the Builtin Logging Topic, which is consistent with Connext DDS 5.3.0 behavior. The default value is FALSE.

3.2.2. Wire Compatibility Participants and endpoints using inconsistent security configuration do not communicate

This release adds support for the new DDS Security 1.1 participant/endpoint security matching, which allows for early detection of incompatible security configurations. To support this feature, participants will announce new parameters as part of the participant/endpoint discovery. See What’s New in 6.0.0 in the Security Plugins Release Notes.

The propagation of these parameters is enabled by default. Since their propagation introduces additional restrictions for participant and endpoint matching, participants and endpoints may stop communicating after upgrading to 6.0.0 if they are using a configuration considered incompatible according to the DDS Security specification.

To support scenarios relying on inconsistent security configurations, the following new properties have been introduced (not used by default):

Table 3.5 New Properties to Enable/Disable Propagation of New Security Parameters During Discovery
Property Name [1] Property Value Description
dds.participant.discovery_config. disable_endpoint_security_info_propagation Optional

If set to FALSE, the endpoint’s security_info is propagated and a DataWriter/DataReader pair needs to use the same security configuration to match. If set to TRUE in both participants, contained DataWriters and DataReaders may communicate for some combinations of inconsistent metadata/data protection kinds.

Default: FALSE
dds.participant.discovery_config. disable_participant_security_info_propagation Optional

If set to FALSE, the participant’s security_info is propagated and a pair of participants needs to use the same Governance’s RTPS, discovery, and liveliness configurations to match. If set to TRUE in both participants, participants may communicate for some combinations of inconsistent Governance’s RTPS, discovery, and liveliness configurations.

Default: FALSE

3.2.3. APIs Changes in DDS types and definitions

The following changes were made to match the DDS Security specification:

  • Added new TopicSecurityAttributes type.
  • Moved the following from EndpointSecurityAttributes to TopicSecurityAttributes:
    • is_read_protected
    • is_write_protected
    • is_discovery_protected
    • is_liveliness_protected
  • Changed the RTI_Security_Exception (DDS_TrustException) definition and removed the RTI_Security_ExceptionCode (DDS_TrustExceptionCode) definition.
  • Changed ReturnCode_t NOT_ALLOWED_BY_SEC (value 13) to NOT_ALLOWED_BY_SECURITY (value 1000). Changes in APIs

  • Added the following APIs to the Access Control plugin interface to match the DDS Security specification:
    • get_topic_security_attributes
    • get_datawriter_sec_attributes and get_datareader_sec_attributes (these replace get_endpoint_sec_attributes)
    • return_participant_sec_attributes, return_datawriter_sec_attributes, and return_datareader_sec_attributes
  • Removed the get_endpoint_sec_attributes API from the Access Control plugin interface.
  • Updated validate_remote_identity to include AuthRequestMessageToken parameters.
  • Removed begin_auth_request and process_auth_request APIs from the Authentication plugin interface.
  • Updated check_remote_datareader to include the relay_only parameter.
  • Updated check_local_datawriter_match and check_local_datareader_match to include publication/subscription data parameters and to remove the tags parameter.
  • Added “const” to non-primitive input parameters of APIs of Authentication, Access Control, and Cryptography plugins. get_datawriter_sec_attributes and get_datareader_sec_attributes must support receiving builtin topic names

Previously, get_datawriter_sec_attributes and get_datareader_sec_attributes did not expect to receive builtin topic names, only user topic names. In this release, to be compliant with DDS Security 1.1, the core libraries can call get_datawriter_sec_attributes and get_datareader_sec_attributes to retrieve the endpoint security attributes for builtin (secure and non-secure) DataWriters and DataReaders. As such, custom security plugins need to be updated to support receiving the following topic name string definitions:

  • DDS discovery topics:
  • DDS liveliness topic:
  • DDS Security secure discovery topics:
  • DDS Security secure liveliness topic:
  • Other DDS Security topics:
  • RTI non-secure topics:
  • RTI secure topics:


[1]These new properties do not need to be prefixed with ‘com.rti.serv.secure.’