GitLab Omniauth openid-connect via Keycloak

How to Use GitLab Self-managed
,
1

I am trying to setup OmniAuth via openid-connect using Keycloak.

I can successfully authenticate in Keycloak. When redirecting back to Gitlab, I get the following

image
image981Ɨ449 240 KB

I followed the docs on OmniAuth via openid-connect and set the callback url as suggested.

GitLab runs at http://<domain>/gitlab.

Here is the full config

gitlab_rails['omniauth_providers'] = [
          { 'name' => 'openid_connect',
            'label' => 'Keycloak',
            'args' => {
              'name' => 'openid_connect',
              'scope' => ['openid','profile'],
              'response_type' => 'code',
              'issuer' => 'http://<domain>/auth/realms//<realm>',
              'discovery' => false,
              'uid_field' => 'uid',
              'client_auth_method' => 'query',
              'send_scope_to_token_endpoint' => false,
              'client_options' => {
                'identifier' => 'gitlab',
                'secret' => '<secret>',
                'authorization_endpoint' => 'http://<domain>/auth/realms/<realm>/protocol/openid-connect/auth',
                'token_endpoint' => 'http://<domain>/auth/realms/<realm>/protocol/openid-connect/token',
                'userinfo_endpoint' => 'http://<domain>/auth/realms/<realm>/protocol/openid-connect/userinfo',
                'redirect_uri' => 'http://<domain>/gitlab/users/auth/openid_connect/callback'
              }
            }
          }
        ]

In Keycloak Iā€™ve set mappers for the following attributes:

  • ā€œNameā€
  • ā€œEmailā€
  • ā€œUsernameā€

Does anyone have an idea what might be wrong?

2

I think the Keycloak authentication is fine. Something goes wrong with the GitLab callback handler?

Started POST "/users/auth/openid_connect" for 159.100.253.188 at 2020-10-17 07:25:24 +0000
Processing by Gitlab::RequestForgeryProtection::Controller#index as HTML
  Parameters: {"authenticity_token"=>"[FILTERED]"}
Completed 200 OK in 1ms (ActiveRecord: 0.0ms | Elasticsearch: 0.0ms | Allocations: 169)
Started GET "/users/auth/openid_connect/callback?state=4e1d5956b6e7e46683632cde9804b370&session_state=aa41a9a4-51bf-4f5f-acf1-135f0bfeb2e4&code=[FILTERED]" for 159.100.253.188 at 2020-10-17 07:25:25 +0000
Processing by OmniauthCallbacksController#failure as HTML
  Parameters: {"state"=>"4e1d5956b6e7e46683632cde9804b370", "session_state"=>"aa41a9a4-51bf-4f5f-acf1-135f0bfeb2e4", "code"=>"[FILTERED]"}
Redirected to https://<domain>/users/sign_in

To me it looks like the authentication first succeeds and then the ā€œOmniauthCallbacksControllerā€ processes the failure page and redirects back to the sign in. However, I see no logs why and what happens.

If I only could see what is in the returned ā€œcodeā€ partā€¦

3

Not sure whether this the problem, you got a duplicate slash in the issuer field. I had problems as well in discovery mode because I firstly had a trailing slash in the issuer field. After I removed it everything worked.

4

Thanks, this was just a typo when creating the question.

Iā€™ve tried lots of different configs but no success.

OpenID-connect works instantly in Gitea but GitLab seems to be broken?

5

any updates on this one? I am willing to do the same integration.

6

We have the setup a bit different:

> gitlab_rails['omniauth_providers'] = [
>   {
>     'name' => 'oauth2_generic',
>     'app_id' => '{{ gitlab_clientid }}',
>     'app_secret' => '{{ gitlab_clientsecret }}',
>     'args' => {
>       client_options: {
>         'site' => '{{ oauth_url }}', # including port if necessary
>         'user_info_url' => '/auth/realms/<realm>/protocol/openid-connect/userinfo',
>         'authorize_url' => '/auth/realms/<realm>/protocol/openid-connect/auth',
>         'token_url' => '/auth/realms/<realm>/protocol/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' =>  'https://{{ gitlab_url }}/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 do remember that the "id_path: [ā€˜subā€™] was essential for coupling this as that was the path keycloak returned the info in.
This does work for existing users, but lately we have problems with users registering themselves via keycloak (blocked account wonā€™t be auto created), but the login for existing users works, and we can also create users and couple them via the users profile.

7

We could not get it working and since we have no GitLab plan which includes support, we switched go Gitea. OIDC worked on the first try.

1 Like
8

You are not the only one struggling with the GitLab OAuth implementation. It is not documented well and there are two outlined providers (oauth2_generic and openid_connect) for general usage. The debugging and syntax outline is very loose.

4 Likes