
.. _section-whats-new-740:

What's New in 7.4.0
*******************

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.

.. Access Control
.. [RTI Issue ID SEC-857]

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).

.. Access Control
.. [RTI Issue ID SEC-1362]

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
<https://community.rti.com/static/documentation/connext-dds/7.4.0/doc/manuals/connext_dds_secure/users_manual/p2_core/access_control.html#rules-for-matching-a-subject-name-in-the-permissionsdoc>`__,
in the *RTI Security Plugins User's Manual*.

.. Access Control
.. [RTI Issue ID SEC-2370]

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 <https://community.rti.com/static/documentation/connext-dds/6.1.2/doc/manuals/connext_dds_secure/release_notes/index.htm#security_plugins/release_notes/WhatsNew/610/ChangesScalability.htm#5.3.7.5_Changed_default_value_of_max_heartbeat_retries_for_secure_volatile_ch...>`__.

-  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
<https://community.rti.com/static/documentation/connext-dds/7.4.0/doc/manuals/connext_dds_secure/users_manual/p2_core/cryptography.html#configuring-reliability-protocol-settings-of-the-secure-key-exchange-topic>`__,
in the *Security Plugins User's Manual* for more information.

.. Discovery and Authentication
.. [RTI Issue ID SEC-1288]

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.

.. Usability
.. [RTI Issue ID SEC-2441]

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).

.. OMG Specification Compliance
.. [RTI Issue ID SEC-2433]

.. _sec_2509:

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.

.. OMG Specification Compliance
.. [RTI Issue ID SEC-2509]

Deprecations and Removals
-------------------------

.. include:: ../../../../../connext_doc.1.0/srcDoc/whats_new/dep_rem_snippet.txt

authentication.key_establishment_algorithm property deprecated
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
As described in :ref:`sec_2509`, the 
plugin-specific property ``authentication.key_establishment_algorithm``
has been deprecated.

.. SEC-2509