Oauth2 authentication logs no extern_uid

We have an gitlab ce installation with an external oauth2 provider.

While users are able to authenticate via the oauth provider, we notice that all logins via this authentication method are logged in as 1 user.

I expect that it is due to an empty extern_uid field, because we see log entries in the gitlab application.log like:

“(OAuth) saving user myemail@example.com from login with extern_uid =>”

We have tried to read the uid (called “sub” by the oauth provider ) into the user attributes, but still the extern_uid stays empty. Any ideas?

It looks a bit like https://github.com/gitlabhq/gitlabhq/issues/9369 but we do not have any extern_uid reported in the logs

Kind regards
Bart

And of course the relevant configuration (with which we have experimented with placing the extern_uid an uid keys):

gitlab_rails[‘omniauth_enabled’] = true
gitlab_rails[‘omniauth_allow_single_sign_on’] = [‘oauth2_generic’]
gitlab_rails[‘omniauth_block_auto_created_users’] = true
gitlab_rails[‘omniauth_providers’] = [
{
‘name’ => ‘oauth2_generic’,
‘app_id’ => ‘ourappid’,
‘app_secret’ => ‘oursecret’,
‘args’ => {
client_options: {
‘site’ => ‘https://oauth.example.com/’, # including port if necessary
‘authorize_url’ => '/auth/,
‘user_info_url’ => ‘/auth/userinfo’,
‘token_url’ => ‘/auth/token’
},
user_response_structure: {
#root_path: [‘data’, ‘user’], # i.e. if attributes are returned in JsonAPI format (in a ‘user’ node nested under a ‘data’ node)
root_path: , # i.e. if attributes are returned in JsonAPI format (in a ‘user’ node nested under a ‘data’ node)
#id_path: ‘sub’,
attributes: { nickname: ‘email’, name: ‘name’, email: ‘email’, extern_uid: ‘sub’ } # if the nickname attribute of a user is called ‘username’
},
‘uid’: ‘sub’,
‘redirect_url’ => ‘http://gitlab1.example.com/users/auth/oauth2_generic/callback’,
# 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.
strategy_class: “OmniAuth::Strategies::OAuth2Generic” # Devise-specific config option Gitlab uses to find renamed strategy
}
}
]

Seems now that this is due to the openid format from our identity provider that gives a JSON formatted reply, but the id is not mapped to the extern_uid. Also tried the openid-connect strategy, still no luck so far, but it seems that the gitlab code need some other changes similar to http://rahul-ghose.blogspot.nl/2014/03/setup-gitlab-with-openam-openid-connect.html or https://github.com/ComputerScienceHouse/gitlab-ce-oidc.
But this renders the code less maintainable which is not something we desire

Some more playing with the oauth_generic module gave us the following conf:

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_providers’] = [
{
‘name’ => ‘oauth2_generic’,
‘app_id’ => ‘CLIENT_ID’,
‘app_secret’ => ‘CLIENT_SECRET’,
‘args’ => {
client_options: {
‘site’ => ‘https://iam.example.com’, # including port if necessary
‘user_info_url’ => ‘/auth/openid_connect/userinfo’,
‘authorize_url’ => ‘/auth/openid_connect/auth’,
‘token_url’ => ‘/auth/openid-connect/token’
},
user_response_structure: {
id_path: [‘sub’], # i.e. if attributes are returned in JsonAPI format (in a ‘user’ node nested under a ‘data’ node)
attributes: { nickname: ‘username’, email: ‘email’ } # if the nickname attribute of a user is called ‘username’
},
},
‘redirect_uri’ => ‘http://gitlab.example.com/users/auth/oauth2_generic/callback’,
# 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: ‘oauth2_generic’, # display name for this strategy
‘strategy_class’: “OmniAuth::Strategies::OAuth2Generic” # Devise-specific config option Gitlab uses to find renamed strategy

}
]

I’m in a similar situation, where everything seems to be working using oauth2_generic
except for the mapping of attributes.
Not sure which attributes GitLab uses, but from your post, I gather that it’s close to
email (for the email)
nickname (Users real name?)
extern_uid (the uid/login)

The OAuth2 server is a Windows ADFS server.
Any tips on how to find what is actually returned by ADFS (OAuth2 server)?
The GitLab log with log_level set to :debug shows
Parameters: {“code”=>"[FILTERED]", “state”=>“e3…”}

Wasn’t successful using Wireshark (total noob)
Also not quite sure how to go about it using: curl, httpie, insomnia

The ADFS admin said that it’s set up like all the others - they are using SAML,
and this is the first OAuth2 client/app. I can probably persuade him to change the
return values, if I know what to ask for.

It’s so far possible to Connect the oauth2_generic validation to an existing account,
but the identifier is blank so when a user tries to login via oauth_generic, then he/she
is logged in to the last active account.

Are you using ssl/tls on the auth server? If so, Wireshark only sees the encrypted response. If you can setup a http version, you can see the response, I was lucky to have a colleague who knew what the response is, so that part was easy for me, but still http made some things clear.

Yes the test-machine has self-signed cert tls/ssl. Initially I thought this was a must. Could try to set up a machine without tls. So a GitLab test server without tls/ssl and a redirect (site) to http rather than https?

Also got a long XML doc with nested tags:

<Roledescriptor ..>
  <fed:ClaimsTypesRequested ..>
     <auth:ClaimType ..>
       <auth:DisplayName>E-Mail Address</auth:Displayname>
       <auth:Description>The e-mail address of the user</auth:Description>
       <auth:DisplayName>Common Name</auth:Displayname>
       <auth:Description>The common name of the user</auth:Description>

So would that translate to something like attributes: { nickname: ‘Common Name’, email: ‘E-Mail Address’ }
with an id_path or root_path : [‘fed:ClaimsTypesRequested’, ‘auth:ClaimType’, ‘auth:Displayname’]
What about user-id attribute used by GitLab: id or external_id?

What we had to do was setup the id_path in the user_response section, apparently this then is set to the (internal) extern_uid variable. By setting up the id_path you can point gitlab to which variable to get for this (in our case it was the “sub” key in the returned json).

Ok so an ‘id_path’ for the user-id and ‘root_path’ for the rest?

yes, our json was quite flat, so we didn’t need the root path, but we needed the id_path