5.5. What’s New in 7.4.0

5.5.1. Improve isolation in large-scale secure systems using domain tags

Domain tags are now allowed in the rules of your Governance and Permissions Documents. Besides the existing numeric and mandatory <id> or <id_range> values, the Security Plugins now support the optional, string-based <tag> and <tag_expression> in the <domains> element of the Governance Document. The allow and deny rules of the Permissions Document can also have <tag> and <tag_expression> as part of their <domains>. A rule will only apply to a DomainParticipant if its domain ID and tag both match the rule.

5.5.2. Adapt permissions at run-time with new support for participant partitions

Starting in this release, a rule in the Permissions Document can match depending on the DomainParticipant partitions. Previously, the <partitions> tag could only appear within a <publish> or <subscribe> element. It indicated the Publisher or Subscriber partitions necessary for a match. Now, the <partitions> tag can be a direct child of the <allow_rule> and <deny_rule> elements. If so, it specifies the DomainParticipant partitions required for a match (instead of the Publisher/Subscriber partitions).

5.5.3. Simplify your permissions by matching a rule with a group of identities

The Security Plugins now support the <subject_name_expression> element in the Permissions Document. This tag is an alternative to the <subject_name> element. The new tag allows binding the permissions in a <grant> section with a group of identities, rather than a specific one.

The <subject_name_expression> element has the same attribute-value assertions as the <subject_name>, but the values can have special characters (such as ‘*’ or ‘?’) used to indicate patterns. For more information, see Rules for matching a subject name in the Permissions Document, in the RTI Security Plugins User’s Manual.

5.5.4. Inactive Secure Key Exchange DataReader now implies inactive DomainParticipant

If your participant discovery and authentication channels were working but your Secure Key Exchange channel was not working for a given remote participant, you previously had to choose between two options:

Set DomainParticipantQos.discovery_config.secure_volatile_writer.max_heartbeat_retries to a small number and risk entering an unrecoverable situation as described in What’s New in 6.1.0.
Set DomainParticipantQos.discovery_config.secure_volatile_writer.max_heartbeat_retries to unlimited and risk an unbounded memory growth on the Secure Key Exchange DataWriter due to samples never getting purged.

Starting in this release, you no longer have to choose between the two options. You can have the best of both options.

If a Secure Key Exchange DataWriter marks a Secure Key Exchange DataReader as inactive (due to a lack of response within the max_heartbeat_retries number of periodic heartbeats), and if allow_unauthenticated_participants = FALSE, then the DataWriter’s DomainParticipant will remove the DataReader’s DomainParticipant as if liveliness were lost, thus making the “unrecoverable situation” recoverable. If allow_unauthenticated_participants = TRUE, then the remote participant will be removed or treated as unauthenticated depending on the status of the Secure Key Exchange DataReader. See Configuring Reliability Protocol Settings of the Secure Key Exchange Topic, in the Security Plugins User’s Manual for more information.

5.5.5. Removed risk of unbounded memory growth on Secure Key Exchange DataWriter

A DataReader is marked as inactive when it does not respond within the max_heartbeat_retries number of periodic heartbeats. This means the DataWriter will not wait for the DataReader to send an ACK/NACK before removing DDS samples.

The default value for max_heartbeat_retries has been decreased from UNLIMITED to 800 for the secure volatile channel. This change removes the risk of unbounded memory growth on the Secure Key Exchange DataWriter due to samples never being purged.

5.5.6. Authentication class_id now conforms to the value in the DDS Security 1.2 Specification

The Builtin Security Plugins now propagate the DDS:Auth:PKI-DH:1.2 class_id by default, instead of the previous value of DDS:Auth:PKI-DH:1.0. The change is done to conform with the DDS Security 1.2 Specification. DomainParticipants still propagate the DDS:Auth:PKI-DH:1.0 class_id to remote DomainParticipants from previous RTI releases (7.3.0 or older Connext Professional releases, and Connext Micro 3.0.3 release).

5.5.7. New standard property to configure shared secret algorithm, to comply with specification

This release of the Security Plugins introduces the dds.sec.auth.key_establishment_algorithm property, as defined in the DDS Security 1.2 specification. The new property deprecates the plugin-specific property authentication.key_establishment_algorithm.

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.

5.5.8. Deprecations and Removals

Deprecated means that the item is still supported in this release, but will be removed in a future release. Removed means that the item is discontinued or no longer supported.

Any deprecations or removals noted in RTI’s documentation serve as notice under the Real-Time Innovations, Inc., Maintenance Policy #4220 and/or any other agreements by and between RTI and customer regarding maintenance and support of RTI’s software. RTI’s current standard terms and support and maintenance policies are available at https://www.rti.com/terms.

5.5.8.1. authentication.key_establishment_algorithm property deprecated

As described in New standard property to configure shared secret algorithm, to comply with specification, the plugin-specific property authentication.key_establishment_algorithm has been deprecated.