Don’t use the same Permissions File for all DomainParticipants

For better performance and reduced network usage, use individual Permissions Files for each DomainParticipant in your secure system. A Permissions File should only specify the permissions for the DomainParticipant loading it.

When you use RTI Security Plugins, the Permissions File specifies what a DomainParticipant is allowed to do, such as what domains/partitions it can join and what topics it can read/write. This Permissions File is always sent during Authentication so that every DomainParticipant knows about every other DomainParticipant’s permissions. The Permissions File is signed by the Permissions CA, which guarantees its authenticity.

Although a single Permissions File could technically be used to specify the permissions of every DomainParticipant in the system, this approach comes with a high overhead:

1. Storage overhead: the shared Permissions File will have multiple entries (corresponding to the permissions of multiple DomainParticipants). Thus, every DomainParticipant will need to store a bigger Permissions File.

2. Network usage overhead: when two DomainParticipants discover each other, the shared Permissions File still needs to be sent both ways---and it’s large. Individual Permissions Files are smaller.

3. Processing and memory consumption overhead: the signature in the received Permissions File needs to be verified against the Permissions CA’s digital certificate. The bigger the Permissions File, the more computational power needed to verify its signature. Searching through a Permissions File with multiple entries also increases the computational cost.

To avoid this overhead, we recommend using individual Permissions Files for each DomainParticipant in your system containing only the grants for that DomainParticipant. Please note that security will not be affected by this implementation---since the Permissions File is signed by the Permissions CA, any DomainParticipant trusting that Permissions CA can verify whether another DomainParticipant has the permissions it claims. For more information, see the “Access Control” chapter of the RTI Security Plugins User's Manual.