When using group mapping, the following caveats apply regardless of which delegated authentication method is used:
- membership in synchronized groups will override any membership locally configured in SonarQube at each login
- membership in a group is synched only if a group with the same name exists in SonarQube
- membership in the default group
sonar-usersremains (this is a built-in group) even if the group does not exist in the identity provider
When group mapping is configured, the delegated authentication source becomes the one and only place to manage group membership, and the user’s groups are re-fetched with each log in.
I think this functionality should be reviewed. Copying group assignments from the authentication provider makes good sense. But it should be possible to define more specific permissions within SonarQube itself; these permissions should take precedence rather than be deleted.
In our use-case we want to be able to assign additional rights to certain users within SonarQube, but we don’t have the ability to easily create/update groups within the authentication system.
Also if using a source control system as the authentication service, you might not wish to create lots of groups just for managing permissions within SonarQube, as this would make the source control system untidy (and the SonarQube admin might then also need to be the source control admin).