SSO Linking overwrites existing user permissions

[daleao]

Issue happens with Authelia. Not tested with other providers.

Steps:

• Followed the steps here to setup SSO.
• Made sure to set <DefaultUsernameClaim>name</DefaultUsernameClaim> in SSO-Auth.xml so linking should happen with Authelia's Display Name field, and ensured that displayname in Authelia's users_database.yml matches my Jellyfin username.
• Made sure to include <RoleClaim>groups</RoleClaim> and <AdminRoles><string>admins</string></AdminRoles> in SSO-Auth.xml, so my user should receive admin role anyway. Ensured that my user's groups in Authelia's users_database.yml includes - admins.
• Clicked to sign in with single sign on.
• Accepted the prompt by Authelia to approve the linking request and let Jellyfin use my information.

Expected result:
Authelia user is linked to Jellyfin user of the same name. Either no changes are made since the user already existed, or the user is granted admin privileges due to having the group indicated within the <AdminRoles> tag.

Result: I am logged in with correct user name, but have no admin privileges. If I log out and try to log back in manually, my password still works, but still no privileges, which means they were effectively overwritten during the linking process.

The value of <CanonicalLinks> in SSO-Auth.xml shows to have linked correctly (user GUID matches the original user's ID).

Inspecting Jellyfin's user database shows that permissions 5 and 6 are set to 0 when they were previously 1.
Manually setting those permissions back to 1 with sqlite3, and then refreshing the Jellyfin web UI causes the linking to be reset (even though it is still in the SSO-Auth.xml file.
So Authelia once again prompts me to confirm the linking. Every time I accept the link, the permissions are set back to 0 and I lose admin privileges.

Effectively means that linked users can't be admins.

[9p4]

I think much of the code is due for a rewrite, it's accumulated a lot of cruft.

[Casuallynoted]

Oooof just ran into this myself on my admin account. Is the only way to fix this by sqlite3ing into the db and correcting it, and then just not using SSO for the admin account?