2.2.2. RTI Security Plugins

2.2.2.1. Interoperability with DomainParticipants that have a domain tag or partitions

Starting in release 7.4.0, the Builtin Security Plugins consider the DomainParticipant’s domain tag and partitions when deciding whether an allow or deny rule matches. If an allow rule doesn’t specify partitions, it will only match against the default empty string partition (“”). If a deny rule doesn’t specify partitions, it will match against any partition (including the default empty string partition). The same behavior applies to domain tags. Your Permissions Document must be explicit when allowing partitions and domain tags; the implicit behavior is to deny access as much as possible.

For example, consider the following rule in a Permissions Document:

<allow_rule>
    <domains>
        <id>0</id>
    </domains>
</allow_rule>
<default>DENY</default>

In previous releases, a DomainParticipant with a subject name matching the grant of this rule would be allowed to publish or subscribe in domain 0, regardless of its domain tag or partitions. Starting in this release, the same DomainParticipant will be denied if it has a domain tag or partition different from the empty string.

As a consequence, if your system has a combination of 7.3.0 or previous DomainParticipants using domain tags or partitions and 7.4.0 or later DomainParticipants, you must update your Permissions Document for both 7.4.0-based and 7.3.0-based DomainParticipants. It should account for the new behavior and include the <partitions> and <tag> or <tag_expression> elements as necessary. These tags must include the must_interpret="false" attribute and value so versions of the Builtin Security Plugins that do not support them don’t fail to parse the Permissions Document.

For example, this change in the previous rule will allow the DomainParticipant with a Migration Guide tag and Permissions Document update partition.

<allow_rule>
    <domains>
        <id>0</id>
        <tag must_interpret="false">Migration Guide</tag>
    </domains>
    <partitions must_interpret="false">
        <partition>Permissions Document update</partition>
    </partitions>
</allow_rule>
<default>DENY</default>

Note that this workaround only works for releases of the Builtin Security Plugins that support the must_interpret attribute (7.0.0 or later). Connext added support for DomainParticipant partitions in the 7.0.0 release and for domain tags in the 6.0.0 release. Communication with secure 6.x DomainParticipants is not possible if they are configured with a domain tag.

2.2.2.2. HMAC-Only mode removed from the Builtin Security Plugins

Release 7.4.0 of the Builtin Security Plugins removes HMAC-Only mode and the features based upon it. Use the Lightweight Builtin Security Plugins instead. Legacy HMAC-Only mode systems can communicate with modern Pre-Shared Key protected systems by using a 7.3.0 Routing Service instance (because it supports both modes).

As a result of the removal, the plugin-specific properties for configuring HMAC-Only mode are also removed: hmac_only.enabled, hmac_only.cryptography.key, and hmac_only.cryptography.max_blocks_per_session are no longer available. This release also removes the authentication.participant_discovery_protection_key and cryptography.rtps_protection_key properties for setting static HMAC keys to compute signatures with.

2.2.2.3. Use new property in place of authentication.key_establishment_algorithm

This release of the Security Plugins introduces the dds.sec.auth.key_establishment_algorithm property, as defined in the OMG DDS Security 1.2 specification. This new property deprecates the authentication.key_establishment_algorithm plugin-specific one. Both properties configure the algorithm used to establish a shared secret during authentication. Their behavior and accepted values are the same. You should use the new standard property instead of the deprecated plugin-specific one, because the deprecated one may be removed in a future release. See Deprecations and Removals in the RTI Connext What’s New.