Attempt to link saml users to ldap by email fails for new users

Summary

If a new users logs into gitlab-ce using omniauth-saml provider whith omniauth_auto_link_ldap_user active and using name_identifier_format=urn:oasis:names:tc:SAML:2.0:nameid-format:persistent the saml response will generate an unique id as uid so matching to an ldap users fails. The user is created anyways for gitlab-ce but uses an possible wrong username and has no group memberships.

Steps to reproduce

  • enable omniauth-saml
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['saml']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_ldap_user'] = true
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_providers'] = [
   {
     "name" => "saml",
     "args": {
             assertion_consumer_service_url: 'https://<gitlab-ce hostname>/users/auth/saml/callback',
             idp_cert_fingerprint: 'C9:36:68:6E:01:9D:EC:FB:E7:C4:A5:B3:ED:A5:3C:E1:A5:56:3C:7F',
             idp_sso_target_url: 'https://<idp hostname>/idp/saml2/SSO/Redirect',
             issuer: 'gitlab-ce',
             name_identifier_format: 'urn:oasis:names:tc:SAML:2.0:nameid-format:persistent',
           },
    "label": 'SAML Login' # optional label for SAML login button, defaults to "Saml"
   }
 ]
  • sign in via saml login with a user who has an valid LDAP entry

What is the current bug behavior?

The gitlab-ce user is created but not linked to the correct LDAP user.

What is the expected correct behavior?

The gitlab-ce users should be created and linked to the correct LDAP user.

Relevant logs and/or screenshots

Error log from application.log 
March 21, 2019 13:18: User "Juergen Wolf" (juergen.wolf@idmt.fraunhofer.de) was created
March 21, 2019 13:18: (SAML) saving user juergen.wolf@idmt.fraunhofer.de from login with admin => false, extern_uid => _771a2686b63f2b8b0e0d97afd4dc85df1d870b17cfebaecfccfc20f17ccc8c9f3dd24bcca3b275e24168b6aa4e524b1968bc87ea4841b2bc6c3b5034c63af4eb
Correct log from application.log after fixing the issue 
March 21, 2019 14:39: No user found using saml provider. Creating a new one.
March 21, 2019 14:39: Correct LDAP account has been found. identity to user: wolf.
March 21, 2019 14:39: User "Juergen Wolf" (juergen.wolf@idmt.fraunhofer.de) was created
March 21, 2019 14:39: (SAML) saving user juergen.wolf@idmt.fraunhofer.de from login with admin => false, extern_uid => _771a2686b63f2b8b0e0d97afd4dc85df1d870b17cfebaecfccfc20f17ccc8c9f3dd24bcca3b275e24168b6aa4e524b1968bc87ea4841b2bc6c3b5034c63af4eb

Results of GitLab environment info

Expand for output related to GitLab environment info 
System information
System:
Current User:	git
Using RVM:	no
Ruby Version:	2.5.3p105
Gem Version:	2.7.6
Bundler Version:1.16.6
Rake Version:	12.3.2
Redis Version:	3.2.12
Git Version:	2.18.1
Sidekiq Version:5.2.5
Go Version:	unknown


GitLab information
Version:	11.8.3
Revision:	3f81311
Directory:	/opt/gitlab/embedded/service/gitlab-rails
DB Adapter:	postgresql
URL:		https://ilvs48.idmt.fraunhofer.de
HTTP Clone URL:	https://ilvs48.idmt.fraunhofer.de/some-group/some-project.git
SSH Clone URL:	git@ilvs48.idmt.fraunhofer.de:some-group/some-project.git
Using LDAP:	yes
Using Omniauth:	yes
Omniauth Providers: saml


GitLab Shell
Version:	8.4.4
Repository storage paths:
  • default: /git_pool/git-data/repositories Hooks: /opt/gitlab/embedded/service/gitlab-shell/hooks Git: /opt/gitlab/embedded/bin/git

Results of GitLab application Check

Expand for output related to the GitLab application check 
Checking GitLab subtasks ...

Checking GitLab Shell ...


GitLab Shell: ... GitLab Shell version >= 8.4.4 ? ... OK (8.4.4)
Running /opt/gitlab/embedded/service/gitlab-shell/bin/check
Check GitLab API access: OK
Redis available via internal API: OK


Access to /var/opt/gitlab/.ssh/authorized_keys: OK
gitlab-shell self-check successful


Checking GitLab Shell ... Finished


Checking Gitaly ...


Gitaly: ... default ... OK


Checking Gitaly ... Finished


Checking Sidekiq ...


Sidekiq: ... Running? ... yes
Number of Sidekiq processes ... 1


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
LDAP authentication... Anonymous. No bind_dn or password configured
LDAP users with access to your GitLab server (only showing the first 100 results)
DN: uid=wolf,ou=personen,ou=idmt,o=fraunhofer,c=de	 uid: wolf


Checking LDAP ... Finished


Checking GitLab App ...


Git configured correctly? ... yes
Database config exists? ... yes
All migrations up? ... yes
Database contains orphaned GroupMembers? ... no
GitLab config exists? ... yes
GitLab config up to date? ... 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)
Init script exists? ... skipped (omnibus-gitlab has no init script)
Init script up-to-date? ... skipped (omnibus-gitlab has no init script)
Projects have namespace: ...
14/1 ... yes
Redis version >= 2.8.0? ... yes
Ruby version >= 2.3.5 ? ... yes (2.5.3)
Git version >= 2.18.0 ? ... yes (2.18.1)
Git user has default SSH configuration? ... yes
Active users: ... 4


Checking GitLab App ... Finished


Checking GitLab subtasks ... Finished

Possible fixes

https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/auth/o_auth/user.rb#L145

A fourth check should fix the problem:

        def find_ldap_person(auth_hash, adapter)
          Gitlab::Auth::LDAP::Person.find_by_uid(auth_hash.uid, adapter) ||
            Gitlab::Auth::LDAP::Person.find_by_email(auth_hash.uid, adapter) ||
            Gitlab::Auth::LDAP::Person.find_by_email(auth_hash.email, adapter) ||            
            Gitlab::Auth::LDAP::Person.find_by_dn(auth_hash.uid, adapter)