Omniauth 500 when blocking new users
Summary
With Omniauth enabled but blocking newly created users, gitlab will return a 500 when attempting to authenticate with a non-existent user.
The use case for the customer is they want to manually create/approve users, rather than having Gitlab create and then block users.
Steps to reproduce
/etc/gitlab/gitlab.rb
Settings
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = false
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_providers'] = [
{
name: 'saml',
args: {
assertion_consumer_service_url: 'https://gitlab.meklar.tech/users/auth/saml/callback',
idp_cert_fingerprint: 'fingerprint',
idp_sso_target_url: 'https://examplecom/samlp/',
issuer: 'urn:example.com',
name_identifier_format: 'urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified',
attribute_statements: { email: ['http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress'] }
},
label: 'Auth SAML2 Login' # optional label for SAML login button, defaults to "Corporate Single Sign On"
}
]
What is the current bug behavior?
Completed 500 Internal Server Error in 93ms (ActiveRecord: 1.2ms |
Elasticsearch: 0.0ms)
NoMethodError (undefined method `persisted?' for nil:NilClass):
ee/lib/ee/gitlab/auth/saml/user.rb:15:in `find_user'
lib/gitlab/auth/o_auth/user.rb:61:in `gl_user'
lib/gitlab/auth/o_auth/user.rb:259:in
`clear_user_synced_attributes_metadata'
lib/gitlab/auth/o_auth/user.rb:233:in `update_profile'
lib/gitlab/auth/o_auth/user.rb:21:in `initialize'
app/controllers/omniauth_callbacks_controller.rb:120:in `new'
app/controllers/omniauth_callbacks_controller.rb:120:in `build_auth_user'
app/controllers/omniauth_callbacks_controller.rb:124:in `sign_in_user_flow'
app/controllers/omniauth_callbacks_controller.rb:97:in `omniauth_flow'
app/controllers/omniauth_callbacks_controller.rb:41:in `saml'
lib/gitlab/i18n.rb:55:in `with_locale'
lib/gitlab/i18n.rb:61:in `with_user_locale'
app/controllers/application_controller.rb:434:in `set_locale'
lib/gitlab/middleware/rails_queue_duration.rb:27:in `call'
lib/gitlab/metrics/rack_middleware.rb:17:in `block in call'
lib/gitlab/metrics/transaction.rb:55:in `run'
lib/gitlab/metrics/rack_middleware.rb:17:in `call'
lib/gitlab/middleware/multipart.rb:103:in `call'
lib/gitlab/request_profiler/middleware.rb:16:in `call'
ee/lib/gitlab/jira/middleware.rb:17:in `call'
lib/gitlab/middleware/go.rb:20:in `call'
lib/gitlab/etag_caching/middleware.rb:13:in `call'
lib/gitlab/middleware/correlation_id.rb:16:in `block in call'
lib/gitlab/correlation_id.rb:15:in `use_id'
lib/gitlab/middleware/correlation_id.rb:15:in `call'
lib/gitlab/middleware/read_only/controller.rb:42:in `call'
lib/gitlab/middleware/read_only.rb:18:in `call'
lib/gitlab/middleware/basic_health_check.rb:25:in `call'
lib/gitlab/request_context.rb:26:in `call'
lib/gitlab/metrics/requests_rack_middleware.rb:29:in `call'
lib/gitlab/middleware/release_env.rb:13:in `call'
Started GET "/favicon.ico" for 127.0.0.1 at 2019-06-06 08:25:35 +0000
What is the expected correct behavior?
Return the user back to the sign-in page
Possible fixes
It looks like the issue primarily due to no user being returned and methods being called on a nil class.
unblock_user(user, "in required group") if user.persisted? && user.ldap_blocked?
to
unblock_user(user, "in required group") if user&.persisted? && user&.ldap_blocked?
Fixes this and allows existing users as well as new users, though there may be other implications.
Reproduced on 11.9.6 and 11.11.2
Edited by Davin Walker