Gitlab Omniauth with openid_connect with azure_ad as backend does not respect gitlab_username_claim
Summary
When using openid_connect with AzureAd, the gitlab_username_claim argument is not working.
Steps to reproduce
Configure omniauth oidc with AzureAd.
Config:
{
name: "openid_connect",
label: "Login with SSO",
icon: "data:image/png;base64,PLEASEPROVIDE",
args: {
name: "openid_connect",
scope: ["openid", "profile", "email"],
response_type: "code",
issuer: "https://login.microsoftonline.com/fill-in/v2.0",
client_auth_method: "query",
discovery: true,
gitlab_username_claim: "mycustomusernamefield",
client_options: {
identifier: "some-uid",
secret: "some-secret",
redirect_uri: "https://my.git.hostname/users/auth/openid_connect/callback"
}
}
}
Example Project
don't have one
What is the current bug behavior?
My username created via omniauth is the first part of the email until the @
What is the expected correct behavior?
The content of mycustomusernamefield should be used. It's included in the id_token, but not in the acces_token or the userinfo endpoint
Relevant logs and/or screenshots
sorry - didn't found anything in the logs
Output of checks
sorry - not run
Results of GitLab environment info
System information
System:
Current User: git
Using RVM: no
Ruby Version: 2.7.7p221
Gem Version: 3.2.33
Bundler Version:2.3.15
Rake Version: 13.0.6
Redis Version: 6.0.16
Sidekiq Version:6.5.7
Go Version: unknown
GitLab information
Version: 15.7.5
Revision: 358d690d91c
Directory: /srv/gitlab
DB Adapter: PostgreSQL
DB Version: 12.12
URL: https://gitlab.re.dac.ted
HTTP Clone URL: https://gitlab.re.dac.ted/some-group/some-project.git
SSH Clone URL: git@ssh.re.dac.ted:some-group/some-project.git
Using LDAP: yes
Using Omniauth: yes
Omniauth Providers: openid_connect, azure_activedirectory_v2
GitLab Shell
Version: 14.14.0
Repository storages:
- default: tcp://gitlab-praefect.gitlab-dev-default.svc:8075
GitLab Shell path: /home/git/gitlab-shell
Results of GitLab application Check
I swear, sidekiqk is running fine - I think, the checks are not correct when using the helm chart?
Checking GitLab subtasks ...
Checking GitLab Shell ...
GitLab Shell: ... GitLab Shell version >= 14.14.0 ? ... OK (14.14.0)
Running /home/git/gitlab-shell/bin/check
gitlab-shell self-check failed
Try fixing it:
Make sure GitLab is running;
Check the gitlab-shell configuration file:
sudo -u git -H editor /home/git/gitlab-shell/config.yml
Please fix the error above and rerun the checks.
Checking GitLab Shell ... Finished
Checking Gitaly ...
Gitaly: ... default ... OK
Checking Gitaly ... Finished
Checking Sidekiq ...
Sidekiq: ... Running? ... no
Try fixing it:
sudo -u git -H RAILS_ENV=production bin/background_jobs start
For more information see:
doc/install/installation.md in section "Install Init Script"
see log/sidekiq.log for possible errors
Please fix the error above and rerun the checks.
Checking Sidekiq ... Finished
Checking Incoming Email ...
Incoming Email: ... Reply by email is disabled in config/gitlab.yml
Checking Incoming Email ... Finished
Checking LDAP ...
LDAP: ... Server: ldapmain
Exception: SSL_connect returned=1 errno=0 state=error: certificate verify failed (unable to get local issuer certificate)
Checking LDAP ... Finished
Checking GitLab App ...
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... yes
Cable config exists? ... yes
Resque config exists? ... yes
Log directory writable? ... yes
Tmp directory writable? ... yes
Uploads directory exists? ... yes
Uploads directory has correct permissions? ... yes
Uploads directory tmp has correct permissions? ... skipped (no tmp uploads folder yet)
Systemd unit files or init script exist? ... no
Try fixing it:
Install the Service
For more information see:
doc/install/installation.md in section "Install the Service"
Please fix the error above and rerun the checks.
Systemd unit files or init script up-to-date? ... can't check because of previous errors
Projects have namespace: ...
2/1 ... yes
1/6 ... yes
1/7 ... yes
1/9 ... yes
Redis version >= 6.0.0? ... yes
Ruby version >= 2.7.2 ? ... yes (2.7.7)
Git user has default SSH configuration? ... yes
Active users: ... 5
Is authorized keys file accessible? ... skipped (authorized keys not enabled)
GitLab configured to store new projects in hashed storage? ... yes
All projects are in hashed storage? ... yes
Checking GitLab App ... Finished
Checking GitLab subtasks ... Finished
Possible fixes
didn't found any
Edited by Markus Siebert