OAuth and LDAP sign up process when user cap set - activation not happening correctly
Summary
There's been reports (here and here) about SAML/OAuth login not working correctly when imposing restrictions upon sign up.
Steps to reproduce
Steps to reproduce the bug are detailed in this comment, where the commenter wrote:
If I now set a user cap according to https://docs.gitlab.com/ee/user/admin_area/settings/sign_up_restrictions.html#set-the-user-cap-number,
my newly created SAML user is active immediately.
If I remove the user and the user cap to test again, the newly created user needs approval first.
I tested with a user cap that hasn't been hit yet (5 with only 1 active user).
What is the current bug behavior?
When signing up with a SAML user while the user cap is greater than the number of users but the block_auto_created_users
setting is set to true
, the newly created SAML user is active immediately.
What is the expected correct behavior?
When signing up with a SAML user while the user cap is greater than the number of users but the block_auto_created_users
setting is set to true
, the newly created SAML user should be blocked upon creation.
Elements to fix
The fix is twofold:
- SAML user activation check currently happens in
ee/lib/ee/gitlab/auth/saml/user.rb
. It should take place in a different spot, more likely inlib/gitlab/auth/o_auth/user.rb
. -
::Gitlab.config.omniauth.block_auto_created_users
is currently used to evaluate whether LDAP users should be blocked upon sign up. This is not correct: for LDAP users,::Gitlab::Auth::Ldap::Config.new(provider).block_auto_created_users
should be evaluated instead.
Edited by Etienne Baqué