GitLab

Created by: explody

We have a problem that may be a bug or may be "we're doing it wrong".

We set up GitlLab for LDAP, which worked great, then proceeded to add SAML as well, with the idea that users could login either with their LDAP creds or via our SSO, since the SSO is not quite ubiquitous in our org yet and also since LDAP contains quite a bit of data that the SSO provider does not (such as Twitter handle, etc.). The fields that overlap in LDAP and our SSO do match up, i.e. email, firstname/lastname, uid (as [email protected]).

The bug is thus:

• A user that has not been created yet can log in via SSO and the user is created on the fly.

June 01, 2014 11:49: User "Org User" ([email protected]) was created
June 01, 2014 11:49: (OAuth) Creating user [email protected] from login with extern_uid => orguser

• If that user logs out, then logs in with LDAP credentials, it works and we can see the user object being updated in the logs:

June 01, 2014 11:51: (LDAP) Updating legacy LDAP user [email protected] with extern_uid => uid=orguser,ou=People,dc=domain,dc=com

• The "bug" occurs if the same user then tries to log in w/ SAML SSO after having logged in with LDAP creds. It appears that GitLab doesn't manage to associate the incoming SAML user with an existing user record, tries to create a new user, and fails on an email address conflict: (we added a few 'puts' lines in the code so we could see what was going on. we also notice that "username" is coming through as blank thought that doesn't seem to affect user creation or login)

==> log/unicorn.stdout.log <== 
{:extern_uid=>"orguser", :provider=>"saml", :name=>"Org User", :username=>"", :email=>"[email protected]", :password=>"stuff", :password_confirmation=>"stuff"}

==> log/production.log <==
Completed 422 Unprocessable Entity in 128ms

ActiveRecord::RecordInvalid (Validation failed: Email has already been taken, Email has already been taken, Username has already been taken, Username already exists):
  lib/gitlab/oauth/user.rb:47:in `create'
  app/controllers/omniauth_callbacks_controller.rb:46:in `handle_omniauth'
  app/controllers/omniauth_callbacks_controller.rb:9:in `block (2 levels) in <class:OmniauthCallbacksController>'
  app/controllers/application_controller.rb:59:in `set_current_user_for_thread'

We thought this might qualify as a bug since the user is gracefully updated when doing auth in order of 1)SAML then 2)LDAP, but throws errors when trying SAML again.

We did notice that there is a 'provider' attribute in the user model, implying that any given user would have only one provider, which also implies to us that a user would only be provided/auth'd from one source. Though since the user model updates when switching auth from SAML to LDAP, that also seems that it would do the same if switching login from LDAP to SAML.

So,

• Is this a bug or is a SAML misconfig preventing the users from being found, leading to the second attempted user creation?
• Should a user be able to auth off of multiple sources, back and forth?