SAML with Azure AD Group Sync: name, login and email cannot be parsed correctly

SonarQube Server / Community Build
,
1

Must-share information (formatted with Markdown):

  • which versions are you using
    SonarQube Server Enterprise Edition 9.9 LTA
    SonarQube Community v25.3.0.104237
  • how is SonarQube deployed: zip, Docker, Helm
    Zip-based installation
  • what are you trying to achieve
    Enable SAML authentication with Azure AD, including group synchronization
  • what have you tried so far to achieve this
    SAML authentication for individual users works perfectly.
    Group used for sync already exists in SonarQube.
    Do not share screenshots of logs – share the text itself (bonus points for being well-formatted)!
  • Issue Description
    Group synchronization causes unexpected behavior in attribute mapping.

When the group attribute is not configured, the “Test Configuration” shows correctly parsed user data:

:white_check_mark:Working

SAML Authentication Test

success

Available attributes

name Ann Lee
email ann.lee@example.com
username ann.lee

Attribute mappings

User name value Ann Lee
User email value ann.lee@example.com
User login value ann.lee

However, once the group attribute is added, the other attributes (name, email, username) are no longer resolved correctly and are instead treated as literal strings:

:cross_mark:Broken

SAML Authentication Test

success

Available attributes

name name
email email
username username
group 463297316424-RL-Administrator 922631523672-RL-Administrator 549515951151-RL-Administrator 479592264783-RL-Administrator

Attribute mappings

User name value name
Groups value 463297316424-RL-Administrator 922631523672-RL-Administrator 549515951151-RL-Administrator 479592264783-RL-Administrator
User email value email
User login value username

Any hint for it? Thank you!

Best Regards,
Lu Wang

2

Hi Lu,

You’ve listed two different SonarQube versions in your post. I can’t help you with 9.9 since it’s EOL. Are you seeing this problem in 25.3?

And if so, can you

  • bump server logging to DEBUG via the UI
  • have someone log in to demonstrate the problem
  • return server logging to INFO via the UI
  • post the relevant logs

?
(Note that server DEBUG logs get big, fast, so you want to limit the time at that log level.)

 
Ann