3.2.4. Security Plugins

The following issues affect backward compatibility in Security Plugins when migrating from Release 6.1.0 to Release 6.1.1 or 6.1.2.

3.2.4.1. Problems checking whether a participant is allowed to exist

In Connext 6.1.0 and below, if a Permissions Document contained conflicting allow and deny rules for a given domain combination, then the rule that took effect when creating or discovering new DomainParticipants was the rule that appeared last in the document. This order of precedence is not the intention of the OMG DDS Security 1.1 specification. In this release, the rule that takes effect by default is the one that appears first in the document.

For example, in previous Connext versions, in the following Permissions Document snippet, a DomainParticipant on domain 12 was incorrectly allowed to be created:

<deny_rule>
    <domains>
        <id>12</id>
    </domains>
</deny_rule>
<allow_rule>
    <domains>
        <id>12</id>
    </domains>
</allow_rule>

This problem has been fixed in release 6.1.1. Now, the first rule will be applied, so a DomainParticipant on domain 12 will fail to be created.

In general, to avoid the question of precedence, we recommend, if possible, rewriting your Permissions Document to eliminate conflicting rules.

To keep backwards compatibility with existing Connext 6.1.0 DomainParticipants that cannot update their Permissions Document, release 6.1.1/6.1.2 will, by default, automatically apply the preference order based on the version of the DomainParticipant associated with the Permissions Document. This behavior can be changed through the new com.rti.serv.secure.access_control.use_610_permissions_rules_precedence property, which supports the following values:

auto (default): use the last applicable rule if the DomainParticipant’s version is known to use the last applicable rule (e.g., for release 6.1.0 or below), and use the first applicable rule otherwise.
false: always use the first applicable rule.
true: always use the last applicable rule.

Note that the default behavior may change in future releases of Connext.

3.2.4.2. Failure loading certificates due to missing keyCertSign when a CA has the KeyUsage X.509 V3 extension

In release 6.0.1, the Security Plugins introduced the ability to enforce the presence of the X.509 v3 extension KeyUsage. In that release, DomainParticipant creation did not fail if you enforced key usage extension and the certificate of the Identity or Permissions CAs was missing the keyCertSign attribute, although DomainParticipant creation should have failed in this case. (See Issue related to missing keyCertSign when a CA has the KeyUsage X.509 V3 extension in the 6.0.1 section.)

In release 6.1.1, DomainParticipant creation now fails in this case, with a message similar to the following:

[CREATE DP] RTI_Security_CertHelper_loadCertsCrls:!keyCertSign in keyUsage X.509 v3 extension. Subject name: [...]

To prevent DomainParticipant creation failure, add keyCertSign as part of the allowed uses in the keyUsage variable of the CA’s configuration file. For example:

keyUsage = cRLSign, keyCertSign

See the RTI Security Plugins Release Notes 6.1.2 for more information on the fix, “Creation of secure DomainParticipant did not fail as expected when its Certificate Authority was missing keyCertSign” (SEC-1820).