Automated group provisioning wtih GitHub as the Authentication provider is unreliable

Anything that could be done to prioritize getting Jira implemented would be appreciated.

I see it was recently moved to unassigned and not in a sprint.

FWIW, based on the test just done, I believe the problem is CAUSED by having to login again, not solved by it.

Usual case

  • User complains cannot access SQ
  • Admin checks and see groups are missing, runs sync manually, confirms groups are correct
  • User logs in successfully to SQ

This particular case

  • User complains cannot access SQ
  • Admin checks and see groups are missing, runs sync manually, confirms groups are correct
  • User tries to login to SQ
    • First, is re-directed to GitHub to re-authenticate 
 this was coincidental in this case I did not ask the user to do anything special
    • Then login fails
    • Admin checks and groups are missing again
  • Admin runs sync manually, confirms groups are correct
  • User logs out of GitHub before logging into SQ (and clears cookies) 
 this was at my request to test to see if this flow was better
  • User tries to login
    • First, is re-directed to GitHub to login / re-authenticate
    • Then login fails
    • Admin checks and groups are missing again
  • Admin runs sync manually, confirms groups are correct
  • User logs out of GitHub before logging into SQ (and clears cookies) 
 the user thought this was the new, better procedure so did it this way without being asked to
  • User tries to login
    • First, is re-directed to GitHub to login / re-authenticate
    • Then login fails
    • Admin checks and groups are missing again
  • Admin runs sync manually, confirms groups are correct
  • User logs in to SQ successfully

Hi,

Are you saying you have a user you can reliably reproduce this with?

 
Thx,
Ann

Now that we have isolated the problem, all users can reproduce this. It happens when the user has to re-authenticate.

The problem seems to be in this code:

o.s.s.a.UserRegistrarImpl is trying to check if the authentication provider results includes the same groups for the user as are currently in the system (as done by the previous background sync). This code is checking for direct membership and not checking for transitive member (because the user is in group CHILD_GROUP and group CHILD_GROUP is in group PARENT_GROUP), so it removes the user from 3 groups.

My conclusion is a guess, i do not have access to the source code. The log lines supporting my guess are:

2025.09.18 13:55:38 DEBUG web[47e4017e-0d86-4d55-a1e6-2ead3a6c642a][o.s.s.a.UserRegistrarImpl] List of groups returned by the identity provider ‘CHILD_GROUP’

2025.09.18 13:55:38 TRACE web[47e4017e-0d86-4d55-a1e6-2ead3a6c642a][sql] time=0ms | sql=select g.uuid as uuid, g.name as name, g.description as description, g.created_at as “createdAt”, g.updated_at as “updatedAt” from groups g where g.name in ( ? , ? , ? , ? ) | params=sonar-users, sunbirddcim//all-organization-members, PARENT_GROUP, GRAND_PARENT_GROUP

2025.09.18 13:55:38 TRACE web[47e4017e-0d86-4d55-a1e6-2ead3a6c642a][sql] time=0ms | sql=select g.uuid as uuid, g.name as name, g.description as description, g.created_at as “createdAt”, g.updated_at as “updatedAt” from groups g where g.name = ? | params=sonar-users
2025.09.18 13:55:38 DEBUG web[47e4017e-0d86-4d55-a1e6-2ead3a6c642a][o.s.s.a.UserRegistrarImpl] Removing group ‘sunbirddcim//all-organization-members’ from user ‘foo’
2025.09.18 13:55:38 TRACE web[47e4017e-0d86-4d55-a1e6-2ead3a6c642a][sql] time=0ms | sql=delete from groups_users where user_uuid = ? and group_uuid = ? | params=AYPNacXETpblgMn6FlY3, AYsLFEBjtL-FLoUNThv_
2025.09.18 13:55:38 DEBUG web[47e4017e-0d86-4d55-a1e6-2ead3a6c642a][o.s.s.a.UserRegistrarImpl] Removing group ‘GRAND_PARENT_GROUP’ from user ‘foo’
2025.09.18 13:55:38 TRACE web[47e4017e-0d86-4d55-a1e6-2ead3a6c642a][sql] time=1ms | sql=delete from groups_users where user_uuid = ? and group_uuid = ? | params=AYPNacXETpblgMn6FlY3, AYsLFEBKtL-FLoUNThvj
2025.09.18 13:55:38 DEBUG web[47e4017e-0d86-4d55-a1e6-2ead3a6c642a][o.s.s.a.UserRegistrarImpl] Removing group ‘PARENT_GROUP’ from user ‘foo’

Hi,

Thanks for narrowing this down. It’s very helpful. This has been re-flagged for the team.

 
Thx,
Ann

Hi @andrew-garland,

Thank you for your patience and for all your investigations efforts.

We believe this is related to Team membership lost on login when GitHub auto-provisioning enabled. (nice catch :eye: :eagle: @Colin ).

I added it to our next sprint!

Thanks

1 Like

Thanks for the update. Hopefully, this time it stays in the sprint, since that issue was previously in sprints Identity-25Q3-3 and Identity-25Q3-2

1 Like

Any update on getting this implemented?

Hi,

FYI, this is currently slated to be fixed in v2026.2 :frowning:

I’m advocating for an earlier fix, but I’m not holding my breath.

 
Ann