Skip to content

Instance-wide SAML Group Role assignment fails to read groups attribute when SAML is in Microsoft AD Format

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Summary

GitLab self-managed instances have a SAML Groups feature which allows you to assign cluster-wide roles to users. This is useful, for example, for giving contractors an "External" role to prevent them having unrestricted view rights to all internal projects.

This seems to work fine in the test spec with the standard SAML markup (see: gitlab-org/gitlab/-/blob/master/spec/fixtures/authentication/saml2_response.xml) however when using Microsoft AD-style SAML responses (see an example here: gitlab-org/gitlab/-/blob/master/spec/fixtures/authentication/adfs_saml_response.xml) GitLab is unable to identify the claimed groups.

Steps to reproduce

  1. Setup Azure AD for SAML in GitLab config, with "External" (or any other) group attribute mapped
  2. Assign an AAD user the group in Step 1 and give them access to the GitLab SAML application
  3. Log in to your GitLab instance with that SAML provider
  4. Identify if the user is correctly marked as "External" or not

What is the current bug behavior?

GitLab does not give user the roles claimed by the groups configured (in this case, "External")

What is the expected correct behavior?

GitLab should map the groups provided in the "groups" attribute to GitLab instance-wide roles:

Your IdP passes Group information to the SP (GitLab) in the SAML Response. To use this response, configure GitLab to identify:

  • Where to look for the groups in the SAML response via the groups_attribute setting
  • Which group membership is requisite to sign in via the required_groups setting
  • When required_groups is empty or not set, anyone with proper authentication is able to use the service. (from: https://docs.gitlab.com/ee/integration/saml.html#saml-groups)

Relevant logs and/or screenshots

Unfortunately there are no errors or warnings during login, despite trying to enable increased log verbosity on my instance; it appears to be caused by ruby-saml, however rather than GitLab itself (? can't confirm). I will try to retrieve logs.

Output of checks

Checks all pass (rake checks) - will collect the requested checks when I get access to the cluster later this week.

Results of GitLab environment info (TODO)

Currently Running: 15.0.3 (upgrading to 15.3, will confirm issue persists)

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check (TODO)

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

Possible fixes

Trying to investigate. Will report back.

Edited by 🤖 GitLab Bot 🤖