Loading
Fix GroupSamlMicrosoftGroupSyncWorker bug
What does this MR do and why?
Fixes a bug where the worker returned early if none of the user's Microsoft groups matched a SAML group link, resulting in lingering memberships when they should have been removed. Aligning the behavior with standard SAML group sync.
References
Screenshots or screen recordings
| Before | After |
|---|---|
How to set up and validate locally
Setting up a Microsoft environment isn't straightforward with our tenant access. For this purpose, the spec tests are likely the easiest way.
If you have full access to an MS environment, it would look something like:
- Simulate SaaS
- Create a top-level group
- Configure a SAML app by following the instructions in: Set up your identity provider - Azure
- Configure Microsoft Azure Active Directory integration
- You can test connectivity using my test script, which requires the test user's Entra object ID: $4812074
- Create over 150 groups in Entra
- Assign all groups to a test user in Entra
- Create a subgroup
- Configure SAML group link in the subgroup
- The group link can be a random name; create a direct membership for the test user here
- SAML authenticate with the test user, ensuring an overage claim is present in the SAML response
- Observe that the direct membership is removed because the group wasn't in the Graph API response.
- Previously, it would not remove them because it would return early due to no group links found by name by #group_links
MR acceptance checklist
Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Edited by Jio Castillo