bigbluebutton / greenlight

A really simple end-user interface for your BigBlueButton server.
GNU Lesser General Public License v3.0
781 stars 3.81k forks source link

Fallback mechanism on external authentication effectively makes email address a primary identifier #5872

Open Ithanil opened 1 week ago

Ithanil commented 1 week ago

In app/controllers/external_controller.rb (https://github.com/bigbluebutton/greenlight/blob/6b1f93d8ca2e536702e0c6638627b31345d3665e/app/controllers/external_controller.rb#L34C1-L40C8) there is a fallback mechanism implemented, which effectively renders the email address a primary identifier of a user. According to the code, it behaves as follows:

1) On Login via external authentication, it checks if a user with external_id already exists 2) If it doesn't exist, it checks if the email address already exists for a user 3) If a user with that email is found, it updates the external_id of that user with the value according to the current login

This is a very unexpected behavior in the context of external authentication, where the external_id should be the identifier of the user, and results in problems in environments where email addresses may eventually be reassigned to new persons.

Consider the following: 1) User A logs into GL3 at some point 2) User A leaves the organization or changes his email address 3) User B joins the organization and receives the email address that User A once had 4) User B logs into GL3 and has now access to the account/rooms of User A, including all recordings

I'm not sure in which context you would want such a fallback, but it should be at the minimum configurable and not be the default.

farhatahmad commented 1 week ago

This was done as a back up when we were migrating from v2 to v3. The fallback can be removed