Discovery and Authentication
============================

.. Release Notes from this point.

:critical:`[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]
