Mattermost-server: Gitlab SSO different domain for auth-,token- and userapi- endpoint not working

[Bobonium]

Summary

GitLab SSO does not allow different domains for the User API Endpoint, Auth Endpoint and Token Endpoint.

Steps to reproduce

• Start mattermost with the following environment variables:

MM_GITLABSETTINGS_AUTHENDPOINT = "https://www.example.org/oauth/authorize"
MM_GITLABSETTINGS_TOKENENDPOINT = "http://ww.example2.org/oauth/token"
MM_GITLABSETTINGS_USERAPIENDPOINT = "http://www.example3.org/api/v4/user"

• Go to System Console->Authentication->GitLab
• All 3 entries in the UI will use the same domain instead of the configured ones

Expected behavior

Users should be able to use different urls for each configuration. In my use case for example Mattermost does not have internet access and can't reach the public gitlab endpoint. At the same time my gitlab users can't reach the private endpoint that my mattermost instance would be able to access.

Observed behavior (that appears unintentional)

If started with different configurations for each of the 3 variables you'll be able to see that only a single domain is used for all 3 configurations in the UI

Possible fixes

It's already possible to configure each value using the configuration file/environment variables, so it should simply accept the configured values for each instead of overwriting them

[amyblais]

@hmhealey Would you know about this?

[hmhealey]

That's definitely done on purpose since most people will use the same domain name for each one of those. I believe we did it that way because people were having trouble setting those correctly. It's been like this for quite a while.

Regardless of what it shows in the System Console, it should keep whatever values you set with environment variables though, so it's simply a UI bug.

@Bobonium How is your Mattermost instance cut off from the internet? Perhaps you could still allow it to access GitLab?

[Bobonium]

Ah OK I will double check that then, to be honest I didn't bother trying to login after I saw the incorrect values in the UI.
To be more precise about my setup it's a k8s cluster so I just don't want unnecessary communication through the Internet.

I can test if it's working in a few days as I'm traveling currently.

[Bobonium]

@hmhealey I can now confirm that the values supplied through the configuration are indeed the used ones and this is merely a UI bug.

[hmhealey]

That's good to hear.

Since this isn't the most common use case, perhaps we leave this as-is for now and maybe revisit it if more people run into it? We have a workaround for it at least since the setting can be changed using environment variables or by editing the config.json directly.

[jasonblais]

We haven't received an update so we'll assume that the problem is fixed or is no longer valid.

If you still experience the same problem, we'd be glad to help you where we can.

[Bacto]

Hi,

I have seen a similar problem.

Some people use the Gitlab SSO implementation to use Keycloak.
This is the case in this post: https://medium.com/@mrtcve/mattermost-teams-edition-replacing-gitlab-sso-with-keycloak-dabf13ebb99e

Doing that, GitLabSettings.AuthEndpoint, GitLabSettings.TokenEndpoint and GitLabSettings.UserApiEndpoint have to be set to different values than the default one.

In this case, the result seen in the interface is not reflecting the configuration.

As an example:

docker run -it --publish 8065:8065 \
  -e MM_GITLABSETTINGS_ENABLE="true" \
  -e MM_GITLABSETTINGS_SECRET="secret" \
  -e MM_GITLABSETTINGS_ID="id" \
  -e MM_GITLABSETTINGS_SCOPE="scope" \
  -e MM_GITLABSETTINGS_AUTHENDPOINT="https://hostname/url-test/auth-test" \
  -e MM_GITLABSETTINGS_TOKENENDPOINT="https://hostname/url-test/token-test" \
  -e MM_GITLABSETTINGS_USERAPIENDPOINT="https://hostname/url-test/userinfo-test" \
   mattermost/mattermost-preview

In this case, I got this:

I totally understand the goal of the "GitLab Site URL" field and I think it should be left like this.
But in this case, the configuration file should only have a GitLabSettings.Url entry to get consistency.

And, to allow other SSO integrations like Keycloak, it could be great to have a generic oauth2 SSO configuration (almost similar to the Gitlab configuration).

There is clearly some traction, as someone even forked Mattermost to add Keycloak SSO support: https://github.com/MattLaw0/platform

I hope you will be able to do something with this :)