Add support for GitLab and GitLab self-hosted instances

[hajekj]

It would be great that if just like with BitBucket support, this extension supported both GitLab and GitLab self-hosted instances for 2FA or external logins.

[whoisj]

I agree, know anyone from GitLab who's be willing to contribute the support?

Support for both GitHub and Bitbucket was supplied by their relative companies. The GitHub authentication support was added by @Haacked from GitHub, and the Bitbucket authentication support was added my @mminns from Atlassian.

I would absolutely love to see a contribution from GitLab to support their services.

[hajekj]

Created issue at GitLab's repo as well: https://gitlab.com/gitlab-org/gitlab-ce/issues/36594

[hajekj]

Okay, so I went ahead and tried looking at how it is done with VSTS (since that's the closest to GitLab's authentication due to OAuth2 support):

Support for GitLab's hosted instance seems quite straightforward - creating a client for OAuth2, showing the logon window the same way like VSTS and then obtaining the personal access token on behalf of the user through their API (docs say this is admin only, which is weird - a user cannot generate their own token through API?).

However, for self-hosted GitLab instances, this can be an issue because they are not really likely to create an OAuth2 client with the same client_id as the one which would exist in GitLab.com's instance (unless modifying directly in the database).

So the idea would be that GitLab would need to create some ultimate client id, which would be embedded within all installations and disabled by default, so only those who wish to use the Git Credential Manager within their instances of GitLab would enable the client_id to exist within their instance to be able to sign in through the Git Credential Manager.

Unfortunately, this requires modifications on GitLab's side, which is written in Ruby and I can't code in Ruby at all. I could take care of the Git Credential Manager's side but not GitLab's. Hopefully the folks at GitLab will notice this thread and maybe help us out.

Edit: Additionally, one solution would be to create a discovery mechanism for the client_id's per instance, say that it would be set as domain's TXT DNS record - gitlab_gcmfw_<client_id> so would could parse the client_id out of the TXT record and use it for authentication, however, I am not really sure how many people would adopt this and if it is even worth doing. Could we maybe try to run some sort of survey of people who would be interested into this feature?

[whoisj]

You're the first person to bring this up directly on the GCM issue tracker. That doesn't mean that there's not a lot of demand for it, but it does likely mean that a survey hosted here would get rather skewed / invalid results.

As for identifying the gitlab_gcmfw_<client_id>, the GCM already has a method for reading / handling user configuration. It might not be necessary to parse an extra file.

Finally, I would add that GitLab likely already has, or at least ought to have, a client OAuth identity that they can use for any/all desktop applications looking to authenticate with them. Generally, the OAuth unique identity is for webapp-to-webapp authentication and not for human-to-webapp authentication.

[hajekj]

I didn't mean parsing a file, I meant doing a discovery of the client_id - I wasn't able to find any kind of global client_id for desktop applications (doesn't mean it doesn't exist) - which would be used for authentication in case there isn't any and the client_id would have to be client specific. For that, a DNS record of TXT type at the instance's domain level could be used.

[whoisj]

Well, with luck somebody from GitLab might come by and offer up some advice/help here.

@ethomson do you have any contacts at GitLab who would be interested in contributing 2FA support to the GCM for Git for Windows users?

[whoisj]

@dscho and @ethomson will be at GitMerge in a few weeks (sadly I will not be ☹️), perhaps they could nudge somebody from GitLab in the direction of this issue, and maybe they could be encouraged to provide the requested feature. 😸

[mminns]

Hi @hajekj the way you suggest supporting hosted GitLab seems very similar to how we do it for Bitbucket Cloud.

There currently isn't direct support for self hosted Bitbucket Server, because they don't get picked up by the URL filtering, i.e. an internal server might just be referred to by an IP address. AFAICS that also applies to GitHub support in the GCM. Though I stand to be corrected.

So adding support only for hosted GitLab would be enough for a 1st step?

However looking forward at some point I would like to add that support, using Basic Auth alone to begin with, for self hosted Bitbucket server instances.

I was wondering if the way to do that was via config file settings or Env Vars listing domain names/ip addresses to identify as Bitbucket server instance. If that makes sense.

OAuth support could follow later. I don't think we would look at embedding 'global' OAuth keys etc into the server products, but rather rely on admins configuring their own instances and GCM clients, again potentially via config files or Env Vars.

[whoisj]

The GCM can match a URL to an authority via string matching, configuration, or environment values. This is how TFS servers are matched by GCM users today.

[mminns]

Ah, I should really read more before I write :)

[whoisj]

Ah, I should really read more before I write :)

Nah, I was only confirming your assertion. You're absolutely correct that this can be done via config and/or environment variables.

[emeryao]

Created issue at GitLab's repo as well: https://gitlab.com/gitlab-org/gitlab-ce/issues/36594

just FYI this issue has been moved here since GitLab reorganize there repos