5. Access Control
Access Control makes sure that DomainParticipants in your system have the right permissions to join your DDS Secure Domains, to publish data on sensitive Topics, and to subscribe to them.
Once a DomainParticipant successfully authenticates, its permissions need to be validated and enforced. In this sense, the DDS Security specification goes beyond many traditional security methods, where an application that is allowed to communicate within a secure system is trusted to access any information in it. Instead, the Access Control Plugin provides fine-grained permissions that let you define whether a DomainParticipant is allowed to join a particular Domain, whether it is allowed to subscribe to a specific Topic within a particular Partition, etc. These permissions lock down the specific access that trusted applications have, so if one application becomes compromised, the damage to the system is limited.
There is a strong relationship between the Access Control Plugin and the Cryptography plugin because encryption keys need to be generated for Secure Entities based on the DomainParticipant’s permissions (see Secure Entities).
When a DomainParticipant is created, the Access Control Plugin will check whether the local Permissions Document has a grant for the DomainParticipant being created, based on its Identity Certificate. Then the plugin will check whether the DomainParticipant has permission to join the Domain and permission to create the necessary entities. This is done by examining the Permissions Document. Permissions Documents are exchanged between DomainParticipants during the Authentication process. This way, it’s possible to check whether the remote participants have permission to join the Domain, to publish/subscribe to certain Topics, etc. The Permissions Documents need to be signed by the Permissions CA, therefore it’s possible to verify that the Permissions Documents provided by remote participants are legitimate.
The Cryptography plugin has an important role in making sure the permissions apply by protecting the data. The Governance Document specifies how Domain-wide permissions are enforced, and how data and metadata is protected on those Domains. Permissions Documents provide granular access control at an individual participant level.
Definition
We will refer to “Governance Document” and “Permissions Document” as the abstract concept that contains the Governance rules or Permission grants that will apply in the system. On the other hand, we will refer to Governance Document and Permissions Document to refer to the XML representation of the Governance rules and Permission grants. XML representation is the only one that is supported in the latest version of the OMG DDS Security specification and also in the current version of the Security Plugins, so we will use these terms interchangeably in this chapter.
Access Control consists of two components: governance and permissions checking. Governance is the process of configuring locally created DomainParticipants, Topics, DataWriters, and DataReaders to perform the right amount of security for the right use case. Permissions checking is the process of making sure locally created and remotely discovered Entities are allowed to do what they want to do. Both governance and permissions checking are enforced by XML documents that are signed by a Permissions Certificate Authority that can be the same as the Identity Certificate Authority that signs Identity Certificates. The XSD definitions of these documents are in XML Validation in the Governance Document and XML Validation in the Permissions Document.
For examples of these documents, refer to Elements of a Connext DDS Secure System. Use these examples just as a reference, you will need to modify their content to match your system configuration (Domains, Topics, and used Identity Certificates) and sign the XML files. To specify that you want to use these files, add the corresponding properties detailed in Table 5.3 and Table 5.4 to the DomainParticipant’s PROPERTY QosPolicy (see QoS Properties).
5.1. Governance Document
The Governance Document is an XML document that specifies how the Domain should be secured. The Permissions CA (specified with the dds.sec.access.permissions_ca property) must sign the Governance Document using S/MIME version 3.2 format (which corresponds to the mime-type application/pkcs7-signature). The signed Governance Document needs to be provided to the plugins using the dds.sec.access.governance property as specified in Table 5.3.
This document configures multiple aspects that apply to the whole Domain, such as:
whether the discovery/liveliness information should be protected and the kind of protection,
whether the whole RTPS message should be protected and the kind of protection,
whether a discovered DomainParticipant that cannot authenticate or fail the authentication should be allowed to join the Domain,
whether any successfully authenticated DomainParticipant should be allowed to join the Domain and see the discovery data without checking the access control policies.
This document also specifies how the information on specific Topics within the Domain should be treated. More specifically, it specifies:
whether the discovery/liveliness information on specific Topics should be sent using the secure (protected) writers or using the regular (unprotected) ones,
whether read/write access to the Topic should be open to all or restricted to the DomainParticipants that have the proper permissions,
whether the metadata information sent on the Topic should be protected and the kind of protection,
whether the payload data (serialized application level data) sent on the Topic should be protected and the kind of protection.
The local DomainParticipant validates the locally loaded Governance Document against the Permissions CA specified in the dds.sec.access.permissions_ca property (see Table 5.3). If the Permissions CA cannot validate the Governance Document, the validation will be retried with the alternative certificates specified in the access_control.alternative_permissions_authority_files property (see Table 5.4). If none of the alternative CAs can validate the file (or if you did not set this property), the creation of the local DomainParticipant will fail.
The local DomainParticipant checks the compatibility of the Governance Document for remotely discovered DomainParticipants by checking the participant security attributes and the endpoint security attributes exchanged in the discovery, as explained in Governance Compatibility Validation.
Further details on the Governance Document: Governance Document
5.2. Permissions Document
The Permissions Document specifies what actions a DomainParticipant is allowed to take in a Secure Domain. For example, it determines whether the DomainParticipant can join the Domain (participant-level rules), whether it can publish or subscribe to particular Topics, Partitions, etc. (endpoint-level rules).
The Permissions Document is stored as an XML file. The Permissions CA must sign the Permissions Document using S/MIME version 3.2 format (which corresponds to the mime-type application/pkcs7-signature). The signed Permissions Document is provided to the Security Plugins using the dds.sec.access.permissions property, as specified in Table 5.3.
The local DomainParticipant validates the Permissions Document against the Permissions CA specified in the dds.sec.access.permissions_ca property (see Table 5.3). If the Permissions CA cannot validate the Permissions Document, the validation will be retried with the alternative certificates specified in the access_control.alternative_permissions_authority_files property (see Table 5.4). If none of the alternative CAs can validate the Permissions Document (or if you did not set this property), the validation process will fail.
The Permissions Document contains a set of grant sections, each of which contains a subject_name section, a validity section, zero or more allow_rule sections, and zero or more deny_rule sections. Each grant contains the permissions of a particular DomainParticipant and binds them to the subject name of the DomainParticipant as defined in the DomainParticipant’s Identity Certificate. The validity tag determines whether the Permissions Document is valid for the current date and time. Please note that in the current version of Connext, the signed Permissions Document only supports validity dates between 1970-01-01T00:00:00Z and 2038-01-19T03:14:08Z. Any dates before 1970-01-01T00:00:00Z will result in an error, and any dates after 2038-01-19T03:14:08Z will be treated as 2038-01-19T03:14:08Z. Currently, Connext will not work if the system time is after January 19th, 2038. RTI intends to address this issue in a future release.
Permissions Documents are exchanged between DomainParticipants during the authentication process to claim and verify permissions. Hence, to conserve bandwidth, it is best for this document to have exactly one grant section, which contains the subject name and rules for the DomainParticipant presenting it.
For more information about the Permissions Document, its structure, and its role in your secured system, see Permissions Document
Using the domains tag you can control what Domains your DomainParticipants are allowed to join (participant-level permissions), as described in Specifying Domain IDs. The following sections describe how to give your DomainParticipants permission to publish and subscribe to different Topics based on the topic name, Partitions, and data tags. These endpoint-level permissions are specified using the elements in the publish and subscribe sections, which are inside the allow_rule and deny_rule sections.
5.2.1. Topics
The topics element defines the DDS Topic names that must be matched for the rule to apply. Topic names may be given explicitly or by means of Topic name expressions. Each topic name or topic-name expression appears in a separate topic sub-element within the topics element. The Topic name expression syntax and matching shall use the syntax and rules of the POSIX fnmatch() function as specified in POSIX 1003.2-1992, Section B.6.
Example (appearing within an allow_rule and within a publish tag):
<allow_rule>
<publish>
<topics>
<topic>Square</topic>
<topic>B*</topic>
</topics>
</publish>
</allow_rule>
The above topic condition would match Topic “Square” and any Topic that starts with a “B”.
5.2.2. Partitions
The partitions element defines the DDS Partition names that must be matched for the rule to apply (see PARTITION QosPolicy in the RTI Connext DDS Core Libraries User’s Manual). Partition names may be given explicitly or by means of partition-name expressions. Each partition name or partition-name expression appears in a separate partition sub-element within the partitions element. The partition-name expression syntax and matching shall use the syntax and rules of the POSIX fnmatch() function as specified in POSIX 1003.2-1992, Section B.6.
Example (appearing within an allow_rule and within a
subscribe tag):
<allow_rule>
<subscribe>
<topics>
<topic>Square</topic>
</topics>
<partitions>
<partition>Partition1</partition>
<partition>Partition2</partition>
<partition>PartitionA*</partition>
</partitions>
...
</subscribe>
</allow_rule>
Note the asterisk in the third partition. POSIX fnmatch() matching is allowed for the partition element.
5.2.2.1. Behavior of the partitions tag within an allow_rule
If the partitions tag is under an allow_rule, it delimits which partitions (specified within partition tags) are allowed. In order for an action (e.g., a publish action) to meet the allowed partitions condition, the set of partitions associated with the DDS Entity performing that action (e.g., a DataWriter for a publish action) must be contained by the set of partitions defined by the allowed partitions condition section.
As a limitation, if the DDS Entity performing an action (e.g., a DataWriter for a publish action) uses patterns in its partitions, these patterns must appear explicitly in the allowed partitions condition section. An exception to this rule is adding the * pattern to the allowed partitions condition section, which will allow the attempted action, regardless of the partitions announced by the DDS Entity.
If there is no partitions section, then the default “empty string” partition is assumed. Hence, the allowed action (e.g., a publish action) would only allow publishing on the “empty string” partition.
Example (appearing within a allow_rule and within a publish tag):
<allow_rule>
<publish>
<topics>
<topic>Square</topic>
</topics>
<partitions>
<partition>A</partition>
<partition>B</partition>
</partitions>
</publish>
...
</allow_rule>
The above allowed partitions condition would be matched if the partitions associated with the DDS Entity performing the action (e.g., DataWriter for publish action) are a subset of the set [A, B]. So it would be OK to publish in partition A, in partition B, or in partition [A, B] but not in partition [A, B, C] 1 or in the “empty string” partition.
5.2.2.2. Behavior of the partitions tag within a deny_rule
If the partitions tag is under a deny_rule, it delimits which partitions (specified within partition tags) are denied. For this condition to be met, the DDS Entity associated with the action (e.g., DataWriter for a publish action) must have a partition that matches one of the partitions explicitly listed in the denied partitions condition section.
In other words, the Access Control Plugin will deny the attempted action if the set of partitions announced by the DDS Entity attempting to perform that action (e.g., DataWriter for a publish action) intersects the set of partitions defined in the denied partitions condition section. For computing the intersection, both concrete partitions and expressions containing patterns are considered. Note that if the DDS Entity only announces partitions containing patterns, it will fall back to the “empty string” partition. Therefore, the action will be denied if the denied partitions condition section intersects with the “empty string” partition.
If there is no partitions section, then the * partition expression is assumed. This means that the deny action (e.g., publish action) would apply regardless of the partitions associated with the DDS Entity (e.g., DataWriter for a publish action).
Example (appearing within a deny_rule and within a publish tag):
<deny_rule>
<subscribe>
<topics>
<topic>Square</topic>
</topics>
<partitions>
<partition>A</partition>
<partition>B</partition>
</partitions>
</subscribe>
...
</deny_rule>
<default>ALLOW</default>
The above denied partitions condition would be matched if the partitions associated with the DDS Entity performing the action (e.g., DataWriter for a publish action) intersect the partition set [A, B]. So, it would be OK to publish in partition C or in the “empty string” partition, but not in partition A, in partition [A,B], or in partition [A, B, C].
5.2.2.3. Partition Mutability
DataWriters need to avoid sending historical data to unauthorized DataReaders joining a new partition. Therefore, there are scenarios where Publishers are not allowed to change partitions. Note that these restrictions do not apply to Subscribers.
The Security Plugins do not allow a Publisher to change the PARTITION QosPolicy after the Publisher has been enabled if the Publisher contains any DataWriter that meets the following two criteria:
The TopicSecurityAttributes for that DataWriter have
is_read_protected(which corresponds toenable_read_access_controlin the Governance Document) set toTRUE.The DataWriter has the DURABILITY QosPolicy kind set to something other than
VOLATILE.
When these two criteria are met, a DataWriter should send historical data only to DataReaders that were passing the topic access control rules at the time the historical data was generated. The rule about PartitionQoS immutability enforces this behavior by conservatively preventing a DataWriter of a protected Topic from sending historical data to DataReaders that were not matched before a PartitionQoS change and that potentially could have failed to pass the topic access control rules.
Figure 5.1 Reliable DataWriter Changing Partitions
5.2.3. Data Tags
The RTI Connext DDS Core Libraries User’s Manual describes the DATATAG QosPolicy as a sequence of (name, value) string pairs that belong to a DataWriter or DataReader (see DATATAG QosPolicy in the Core Libraries User’s Manual). The Access Control Plugin uses these tags to determine whether or not a DataWriter or DataReader is allowed to exist according to the Permissions Document. Inside the Permissions Document, the data_tags element may appear within a publish or subscribe element. data_tags may contain one or more tag elements, each containing a name and a value element. For example:
<subscribe>
<topics>
<topic>Sq*</topic>
</topics>
<data_tags>
<tag>
<name>Department</name>
<value>Engineering</value>
</tag>
<tag>
<name>Seniority</name>
<value>Senior</value>
</tag>
<tag>
<name>Title</name>
<value>*Software*</value>
</tag>
</data_tags>
</subscribe>
Note the asterisk in the third tag’s value. POSIX fnmatch() matching is allowed for the value element, but not for the name element.
For further information on data tags, refer to Data Tagging.
5.2.3.1. Behavior of data_tags within an allow_rule
If the data_tags are under an allow_rule, then the data_tags delimit an allowed data tags condition section. In order for an action (e.g., a publish action) to meet the allowed data tags condition, the set of the data tags associated with the DDS Endpoint performing the action (e.g., a DataWriter for a publish action) must be contained in the set of data tags defined by the allowed data tags condition section. If there is no data_tags section, then the default empty set is assumed. This means that the allow action (e.g., publish action) would only allow publishing if there are no data tags associated with the DDS Endpoint (e.g., DataWriter for a publish action).
Example (appearing within an allow_rule and within a publish tag):
<allow_rule>
<publish>
<topics>
<topic>Square</topic>
</topics>
<data_tags>
<tag>
<name>aTagName1</name>
<value>aTagValue1</value>
</tag>
</data_tags>
</publish>
</allow_rule>
The above allowed data tags condition would be matched if the data tags associated with the DDS Entity performing the action (e.g., DataWriter for publish action) are a subset of the set [(aTagName1, aTagValue)]. So it would be OK to publish using a DataWriter with no associated data tags, or a DataWriter with a single tag with name aTagName1 and value aTagValue1.
5.2.3.2. Behavior of data_tags within a deny_rule
If the data_tags are under a deny_rule, then the data_tags delimit a denied data tags condition section. For this condition to be met, the DDS Entity associated with the action (e.g., DataWriter for a publish action) must have a data tag name and value pair that matches one of the data tags explicitly listed in the denied data tags condition section. If there is no data_tags section, then the “set of all possible tags” set is assumed as default. This means that the deny action (e.g., deny publish action) would apply regardless of the data tags associated with the DDS Endpoint (e.g., DataWriter for a publish action).
Example (appearing within a deny_rule and within a publish tag):
<deny_rule>
<publish>
<data_tags>
<tag>
<name>aTagName1</name>
<value>aTagValue1</value>
</tag>
</data_tags>
</publish>
</deny_rule>
The above denied data tags condition would be matched if the data tags associated with the DDS Entity performing the action (e.g., DataWriter for a publish action) intersect the set [(aTagName1, aTagValue1)]. So it would not deny publishing using a DataWriter with no associated data-tags, or a DataWriter with a single tag with name aTagName2, or a DataWriter with a single tag with name aTagName1 and value aTagValue2. But it would deny publishing using a DataWriter with two associated data tags [(aTagName1, aTagValue1), (aTagName2, aTagValue2)]. Table 5.1 analyzes other scenarios for this concrete example.
DataWriter Tag(s) |
Allow/Deny |
|---|---|
<tag>
<name>aTagName1</name>
<value>aTagValue1</value>
</tag>
|
Deny |
<tag>
</tag>
|
Allow |
<tag>
<name>aTagName1</name>
<value>aTagValue2</value>
</tag>
|
Allow |
<tag>
<name>aTagName2</name>
<value>aTagValue1</value>
</tag>
|
Allow |
<tag>
<name>aTagName1</name>
<value>aTagValue1</value>
</tag>
<tag>
<name>aTagName2</name>
<value>aTagValue2</value>
</tag>
|
Deny |
5.4. Advanced Access-Control Concepts
5.4.1. Participant-Level Permissions, Endpoint-Level Permissions, and Unsecure DomainParticipants
As mentioned earlier, you can control whether the Access Control Plugin will check participant-level permissions and endpoint-level permissions for remote participants with the enable_*_control Governance rules (see Related Governance Rules). The Access Control Plugin checks these permissions in different stages of the communication, so they are independent. (Note that successfully authenticated remote participants must present a grant matching the subject name in its Identity Certificate, even though remote permissions checking is disabled. Authenticated participants failing to provide such a grant will be rejected.)
The enable_join_access_control Governance rule controls whether the Access Control Plugin will check participant-level permissions for remotely discovered participants. Your local participant (P1) checks participant-level permissions when it discovers and authenticates a remote participant (P2). When enable_join_access_control = TRUE, P1 will check whether P2 has permission to join the Secure Domain. In other words, P1 will check whether P2 has an allow_rule that includes this Domain in its Permissions Document (as specified with the domains tag). When enable_join_access_control = FALSE, P1 skips this check.
In turn, enable_read_access_control, and enable_write_access_control Governance rules control whether the Access Control Plugin will check endpoint-level permissions for both locally created and remotely discovered Endpoints. When enable_read_access_control = TRUE for a given Topic (T), P1 will enforce permissions on locally created DataReaders of Topic T. Also, P1 will check whether P2 DataReaders have permission to subscribe to Topic T. In other words, when enable_read_access_control = TRUE , P1 will check:
Whether P1 has an
allow_rulethat includes permissions to subscribe to Topic T (as specified with the subscribe tag). This check takes place upon the creation of a DataReader for Topic T.Whether P2 has an
allow_rulethat includes permissions to subscribe to Topic T (as specified with the subscribe tag). This check takes place upon the discovery of a DataReader for Topic T in P2.
The same logic applies to enable_write_access_control and DataWriters.
When allow_unauthenticated_participants = TRUE, unsecure DomainParticipants will be allowed to join the Domain. Since unsecure DomainParticipants do not load the Security Plugins, participant-level permissions and endpoint-level permissions for unsecure participants cannot be verified.
Continuing with our previous example, a remote unsecure participant (P3) will not load the Security Plugins; therefore, it cannot be bound to a Permissions or Governance Document. From P1’s perspective, this is similar to having a Permissions Document that denies permissions for publishing/subscribing to any secure Topic (but not for joining the Domain). As a result, P3 has permission to join any Secure Domain that sets allow_unauthenticated_participants = TRUE. However, P3 is only allowed to subscribe to Topics that do not enforce read access control (enable_read_access_control = FALSE) and is only allowed to publish Topics that do not enforce write access control (enable_write_access_control = FALSE). Please note that if allow_unauthenticated_participants = FALSE for this domain, communication ends when P1 fails to authenticate P3; neither endpoint discovery nor Permissions checks happen in this case.
- To summarize:
When
enable_read_access_control=TRUE, the Topic is protected from unauthorized DataReaders (only participants that have permissions to subscribe to that Topic can subscribe to it).When
enable_read_access_control=FALSE, any DataReader of this Topic can subscribe to it (provided that the DomainParticipant this DataReader belongs to, succeeds in joining the Secure Domain).
Therefore, enabling read access control (enable_read_access_control = TRUE) does not affect secure participants’ ability to publish a particular Topic. However, it does affect the unsecure participants’ ability to subscribe to that Topic, since only secure participants with permissions to subscribe to that Topic will be allowed to do so.
Also note that enable_read_access_control = TRUE will enforce checks on both locally created and remotely discovered DataReaders, regardless of the value of enable_join_access_control. The same logic applies to enable_write_access_control and DataWriters.
5.4.2. Access Control and Unauthenticated Participants
The following matrix shows the security implications of the combinations of allow_unauthenticated_participants and enable_join_access_control. As described in allow_unauthenticated_participants (domain_rule), allow_unauthenticated_participants determines whether participants failing to authenticate will be allowed to communicate in the system, whereas enable_join_access_control determines whether the participant-level permissions of successfully authenticated remote participants will be checked. In other words, allow_unauthenticated_participants deals with the result of the authentication process (performed right after the participant discovery phase); enable_join_access_control deals with the result of a participant-level permissions check (performed right after the remote participant is successfully authenticated). Also note that the participant-level permissions check does not apply to allowed unauthenticated remote participants (i.e., unauthenticated remote participants that are allowed in the Domain because allow_unauthenticated_participants = TRUE).
|
|
Security Implications |
|---|---|---|
|
|
Participants failing to authenticate (including unsecure participants) cannot join the Secure Domain. Once a remote secure participant successfully authenticates, the local participant trusts it to communicate in the Domain and its permissions are not checked. Note that the Authentication Plugin always checks whether the local secure participant has permissions to join the Domain, regardless of |
|
|
Participants failing to authenticate (including unsecure participants) cannot join the Secure Domain. When a remote secure participant successfully authenticates, its permissions to joining the Domain are locally checked. The remote participant will only be allowed in the Domain if it has the right permissions. |
|
|
Participants failing to authenticate (including unsecure participants) can join the Secure Domain. However, they can only publish to Topics that are not protected against unauthorized DataWriters and can only subscribe to Topics that are not protected against unauthorized DataReaders. |
|
|
Participants failing to authenticate (including unsecure participants) can join the Secure Domain. However, they can only publish to Topics that are not protected against unauthorized DataWriters and can only subscribe to Topics that are not protected against unauthorized DataReaders. When a remote secure participant successfully authenticates, its permissions to joining the Domain are locally checked. The remote participant will only be allowed in the Domain if it has the right participant-level permissions. |
5.5. Properties for Configuring Access Control
Table 5.3 lists the properties that you can set to configure Access Control. These properties are configured through the DomainParticipant’s PROPERTY QosPolicy (see QoS Properties).
Property Name |
Property Value Description |
|---|---|
|
Required This Permissions Certificate Authority is used for signing access control governance and permissions XML files and verifying the signatures of those files. The Permissions Certificate Authority file may or may not be the same as the Identity Certificate Authority file. Two participants that want to securely communicate with each other must use the same Permissions Certificate Authority. The document should be in PEM format. You may specify either the file name or the document contents. If specifying the file name, the property value must have the prefix "data:,-----BEGIN CERTIFICATE-----\nabcdef\n-----END CERTIFICATE-----"
Note that the two String. Default: |
|
Required The signed document that specifies the level of security required per Domain and per Topic (see Governance Document). The Permissions CA ( You may specify either the file name or the document contents. If specifying the file name, the property value must have the prefix "data:,MIME-Version: 1.0\nContent-Type:...boundary=\"---7236--\"\n\n"
Note that for signed XML files, all whitespace characters (‘ ‘, ‘r’, ‘n’) are significant, and all quotes must be escaped by a backslash. The safest way to get the correct property value is to call the String. Default: |
|
Required The signed document that specifies the access control permissions per Domain and per Topic (see Permissions Document) for individual DomainParticipants identified by subject names. The Permissions CA ( The The signed Permissions Document only supports validity dates between 1970-01-01T00:00:00Z and 2038-01-19T03:14:08Z. Any dates before 1970-01-01T00:00:00Z will result in an error, and any dates after 2038-01-19T03:14:08Z will be treated as 2038-01-19T03:14:08Z. Currently, Connext will not work if the system time is after January 19th, 2038. You may specify either the file name or the document contents. If specifying the file name, the property value must have the prefix “file:” (no space after the colon), followed by the fully qualified path and name of the file. If specifying the contents of the document, the property value must have the prefix “data:,” (no space after the comma), followed by the contents inside the document. For example: "data:,MIME-Version: 1.0\nContent-Type:...boundary=\"---7236--\"\n\n"
Note that for signed XML files, all whitespace characters (‘ ‘, ‘r’, ‘n’) are significant, and all quotes must be escaped by a backslash. The safest way to get the correct property value is to call the String. Default: |
Property Name (prefix with |
Property Value Description |
|---|---|
|
Optional A comma-separated list of alternative Permissions CA certificates. If verification of either the Permissions Document or the Governance Document fails with the main certificate ( This property value may optionally contain String. Default: |
|
Optional How to deal with conflicting allow/deny rules in a Permissions Document when checking for a Topic, DataWriter, or DataReader’s permission to exist.
Boolean. Default: |
|
Optional How to set the value of
Boolean. Default: |
|
Optional How to determine a match between a DataWriter or DataReader’s Partitions and an “allowed partitions” condition in a Permissions Document.
For example, if a DataWriter has Partitions [A, B], and a Permissions Document allows Partitions [B, C], then when Boolean. Default: |
|
Optional How to deal with conflicting allow/deny rules in a Permissions Document when checking for a DomainParticipant’s permission to exist.
Enum: Default: |
- 2
Assuming you used
com.rti.serv.secureas the alias to load the plugin. If not, change the prefix to match the string used withcom.rti.serv.load_plugins, followed by the.character.