5.2.2. Discovery and Authentication

5.2.2.1. [Critical] Authenticated participant could not replace unauthenticated one if QoS changed during authentication

Regarding the Governance Document tag allow_unauthenticated_participants, the DDS Security 1.2 specification states the following: :

Additionally, a DomainParticipant that later authenticates would kick out the unauthenticated DomainParticipant if it has the same GUID.

The Security Plugins implemented this behavior in Connext 7.3.0, but the following scenario did not work as expected:

  • ParticipantA discovers ParticipantC, which is unauthenticated.

  • Then, ParticipantA discovers ParticipantB, which has the same GUID as ParticipantC.

  • While ParticipantB is in the middle of being authenticated, ParticipantA receives a QoS change from ParticipantC.

In this scenario, when ParticipantB was about to finish being authenticated, ParticipantA incorrectly failed to authenticate ParticipantB and generated a log message similar to this one:

{"plugin_method":"PRESParticipant_authorizeRemoteParticipant"}]}],"m":"authenticated trusted state remote participant aaaaaaaa.bbbbbbbb.ccccccc does not match the one received through discovery by local participant dddddddd.eeeeeeee.ffffffff, removing participant...

Now, a QoS change by ParticipantC does not interfere with the authentication of ParticipantB.

[RTI Issue ID SEC-2738]