Good news is that Iāve been able to reproduce the problem youāre observing above. Bad news is that itās still unclear why this doesnāt work. To document, hereās my changes to /etc/gitlab/gitlab.rb
in the GitLab Ominbus image based on your changes above:
gitlab_rails['omniauth_enabled'] = true
gitlab_rails['omniauth_allow_single_sign_on'] = ['oauth2_generic']
gitlab_rails['omniauth_block_auto_created_users'] = false
gitlab_rails['omniauth_auto_link_saml_user'] = true
gitlab_rails['omniauth_providers'] = [
{
'name' => 'oauth2_generic',
'app_id' => '<app_id>',
'app_secret' => '<app_secret>',
'args' => {
client_options: {
'site' => 'http://<mattermost_host>:8065/', # including port if necessary
'user_info_url' => '/api/v4/users/me'
},
user_response_structure: {
root_path: [], # i.e. if attributes are returned in JsonAPI format (in a 'user' node nested under a 'data' node)
attributes: { nickname: 'username' } # if the nickname attribute of a user is called 'username'
},
# optionally, you can add the following two lines to "white label" the display name
# of this strategy (appears in urls and Gitlab login buttons)
# If you do this, you must also replace oauth2_generic, everywhere it appears above, with the new name.
name: 'Mattermost', # display name for this strategy
strategy_class: "OmniAuth::Strategies::OAuth2Generic" # Devise-specific config option Gitlab uses to find renamed strategy
}
}
]
and the configuration of the OAuth2 application in Mattermost:
Is Trusted: No
Client ID: <client_id>
Client Secret: ***************
Callback URLs: http://<gitlab_host>/users/auth/Mattermost/callback
Created by test on Wednesday, March 21, 2018
Here are the Gitlab logs associated with an attempt to authorize:
==> /var/log/gitlab/gitlab-rails/production.log <==
Started POST "/users/auth/Mattermost" for 172.17.0.1 at 2018-03-21 12:44:57 +0000
Processing by Gitlab::RequestForgeryProtection::Controller#index as HTML
Parameters: {"authenticity_token"=>"[FILTERED]"}
Completed 200 OK in 1ms (ActiveRecord: 0.0ms)
==> /var/log/gitlab/gitlab-rails/production_json.log <==
{"method":"POST","path":"/users/auth/Mattermost","format":"html","controller":"Gitlab::RequestForgeryProtection::Controller","action":"index","status":200,"duration":2.31,"view":0.0,"db":0.0,"time":"2018-03-21T12:44:57.739Z","params":{"_method":"post","authenticity_token":"[FILTERED]"},"remote_ip":null,"user_id":null,"username":null}
==> /var/log/gitlab/gitlab-rails/production.log <==
Started GET "/users/auth/Mattermost/callback?code=[FILTERED]&state=3e78b546e6874487c18207845bc68158e6fbcff86085b49f" for 172.17.0.1 at 2018-03-21 12:44:57 +0000
Processing by OmniauthCallbacksController#failure as HTML
Parameters: {"code"=>"[FILTERED]", "state"=>"3e78b546e6874487c18207845bc68158e6fbcff86085b49f"}
Redirected to http://localhost:9090/users/sign_in
Completed 302 Found in 5ms (ActiveRecord: 0.0ms)
==> /var/log/gitlab/unicorn/unicorn_stdout.log <==
I, [2018-03-21T12:47:29.527107 #841] INFO -- omniauth: (Mattermost) Callback phase initiated.
E, [2018-03-21T12:47:29.532019 #841] ERROR -- omniauth: (Mattermost) Authentication failure! invalid_credentials: OAuth2::Error,
==> /var/log/gitlab/gitlab-rails/production_json.log <==
{"method":"GET","path":"/users/auth/Mattermost/callback","format":"html","controller":"OmniauthCallbacksController","action":"failure","status":302,"duration":6.67,"view":0.0,"db":0.0,"location":"http://localhost:9090/users/sign_in","time":"2018-03-21T12:44:57.769Z","params":{"code":"[FILTERED]","state":"3e78b546e6874487c18207845bc68158e6fbcff86085b49f"},"remote_ip":"172.17.0.1","user_id":null,"username":null}
I do note that Gitlab never reaches out to Mattermost on the user_info_url but decides that the authentication failed from the sole interaction against /oauth/authorize. Nothing in the response from Mattermost suggests the authentication failed, so Iām guessing GitLab is expecting something that Mattermost isnāt sending.
I might suggest reaching out to GitLab at this point for assistance, though thereās a few more things Iād like to try myself as well.