6. Access Control
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 may or may not be the same as the identity certificate authority that signs identity certificates. The XSD definitions of these documents are in $(NDDSHOME)/resource/schema/dds_security_governance.xsd and dds_security_permissions.xsd.
Examples of these documents are in rti_workspace/version/examples/dds_security/xml/, see Governance.xml and PermissionsA.xml. Use these files just as a reference, you will need to update their content/create new files to match your system configuration (domains, topics, and used identity certificates) before signing them. To specify that you want to use these XML files, add the properties in Table 6.1 DDS Security Properties for Configuring Access Control and Table 6.2 RTI Security Plugins Properties for Configuring Access Control to the DDS_DomainParticipantQos property.
|
Property Name |
Property Value Description |
|
dds.sec.access.permissions_ca |
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, but both files are generated in the same way. See the tables at the beginning of 5. Authentication for the steps to generate this 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 "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:,-----BEGIN CERTIFICATE-----\nabcdef\n-----END CERTIFICATE-----" Note that the two “\n” characters are required. Default: NULL |
|
dds.sec.access.governance |
Required The signed document that specifies the level of security required per domain and per topic. To sign an XML document with a Permissions Certificate Authority, run the following OpenSSL command (enter this all on one line): % openssl smime -sign -in Governance.xml -text -out signed_Governance.p7s -signer cacert.pem -inkey cakey.pem Then set this property value to signed_Governance.p7s. 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 fread() function on the file and use the resulting buffer as the property value. Default: NULL |
|
dds.sec.access.permissions |
Required The signed document that specifies the access control permissions per domain and per topic. The <subject_name> element identifies the DomainParticipant to which the permissions apply. Each subject name can only appear in a single <permissions> section within the XML Permissions document. The contents of the <subject_name> element should be the X.509 subject name for the DomainParticipant, as given in the "Subject" field of its Identity Certificate. A <permissions> section with a subject name that does not match the subject name given in the corresponding Identity Certificate will be ignored. To sign an XML document with a Permissions Certificate Authority, run the following OpenSSL command (enter this all on one line): % openssl smime -sign -in PermissionsA.xml -text -out signed_PermissionsA.p7s -signer cacert.pem -inkey cakey.pem Then set this property value to signed_PermissionsA.p7s. The signed permissions document only supports validity dates between 1970010100 and 2038011903. Any dates before 1970010100 will result in an error, and any dates after 2038011903 will be treated as 2038011903. Currently, Connext DDS 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 fread() function on the file and use the resulting buffer as the property value. Default: NULL |
|
Property Name (prefix with ‘com.rti.serv.secure.’)1 Assuming you used ‘com.rti.serv.secure’ as the alias to load the plugin. If not, change the prefix to match the string used with com.rti.serv.load_plugins, followed by the '.' character. |
Property Value Description |
|
access_control. |
Optional A comma-separated list of alternative Permissions CA certificates. If the verification of a file fails with the main certificate (permissions_ca/permissions_authority_file), verification will be retried with all of the corresponding alternative certificates. If none of the alternative certificates can be used to verify the file, the verification process will fail. If any of the alternative certificate files fail to be loaded, the DomainParticipant creation will fail. Default: NULL |
|
access_control. |
Optional How to deal with conflicting allow/deny rules in a Permissions Document. If TRUE, then the last rule will take precedence, which is consistent with Connext DDS 5.3.0 behavior. If FALSE, then the first rule will take precedence, which is consistent with the intended behavior of the DDS Security specification. Default: FALSE |
|
access_control.use_530_logging_protection |
Optional How to set the value of <metadata_protection_kind> for the Builtin Logging Topic. If TRUE, then the value will be NONE, which is consistent with Connext 5.3.0 behavior. If FALSE, then the value will be SIGN, which is consistent with the behavior of the DDS Security specification. Default: FALSE |
|
access_control.use_530_partitions |
Optional How to determine a match between a DataWriter or DataReader's partitions and an "allowed partitions" condition in a Permissions Document. If TRUE, then an entity is matched if it has at least one partition in the condition; this is consistent with Connext 5.3.0 behavior. If FALSE, then an entity is matched only if all of its partitions are in the condition; this is consistent with the behavior of the DDS Security specification. For example, if a DataWriter has partitions [A, B], and a Permissions Document allows partitions [B, C], then when use_530_partitions = TRUE, the DataWriter is allowed because B is allowed. When use_530_partitions = FALSE, the DataWriter is not allowed because A is not allowed. Default: FALSE |
© 2020 RTI