2

I'm trying to connect to a self-managed Gitlab server that runs on a machine inside a company's network from outside this network.

Context

To access this network network, the user is required to pass a reverse proxy and log in via the company's Azure AD and SAML authentication (image below). This works fine when it comes to the Gitlab web app (left branch in the image): Upon trying to access the network, the user is prompted to use the browser-based SSO. The token that is generated is then re-used to authenticate the user for the Gitlab instance, where authentication via Azure OAuth is set up as well.

Issue

The issue is in using the git cli to interact with the git server (push, pull, etc.). The redirect to the SSO triggers the error below:

> git push origin master
fatal: unable to update url base from redirection:
  asked for: https://gitserver.companyurl.com/user/repo.git/info/refs?service=git-receive-pack
   redirect: https://login.microsoftonline.com/<azure_tenant_id>/saml2?SAMLRequest=<base64encoding of SSO portal>

Question

Is it possible to configure git such that the browser-based SSO is triggered upon e.g. git push, and the redirect described above does not raise an exception? Specifically, the following would be ideal:

  • User executes a git push
  • Browser pops up, asks for SSO through Azure AD
  • The request 'enters' the companies network
  • Ideally: The same token is re-used to authenticate against the git server. However, the use of user:pwd combination or access tokens would be fine as well.
  • The git push requests is completed successfully

I'm aware that this wouldn't work on headless systems without a browser, that's a restriction that would be acceptable.

enter image description here

Daniel Lenz
  • 3,334
  • 17
  • 36
  • 1
    Idk if this is helpful, but AWS uses git's credential helper configuration to integrate with their SSO: https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-unixes.html#setting-up-https-unixes-credential-helper – xdhmoore Nov 07 '20 at 20:04
  • 1
    That is really helpful, I wasn't aware of this! I'll see if I can find something similar for MS Azure. – Daniel Lenz Nov 07 '20 at 20:27
  • Unless you have disabled it, and you can't get the helper to work, users can use [PATs](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) to login – fredrik Nov 07 '20 at 20:39
  • I have also experienced a CLI-to-browser-back-to-CLI auth flow in some of Google's Cloud's CLI tools. I think something like what you want is possible, but I don't know how much you'd have to do from scratch. – xdhmoore Nov 07 '20 at 22:08

1 Answers1

2

What you're asking for isn't possible. Git doesn't have a way to spawn a browser (since one need not even be installed) and even if it did, it wouldn't have a way to extract any token or credentials from the browser it spawned.

You may, however, find a custom credential helper useful if you can cause it to invoke a browser like you want and then emit the token. Some environments also want to use a cookie for this purpose, and Git can use the http.cookiefile to read cookies in Netscape format. You could also set up a standard proxy configuration using the http_proxy environment variable and the user's credentials, but be careful that your proxy speaks HTTP/1.1 properly and doesn't perform any filtering, because broken proxies break Git in a variety of subtle ways.

I can't speak for GitLab, but I know GitHub also has support for SAML SSO built-in, so a reverse proxy isn't necessary. In such a case, you can continue to use personal access tokens or SSH keys to access the server while still requiring SSO for the web interface.

I should point out that in general restricting access like this using a reverse proxy in front of the Git host can break automation. You may want to allow SSH keys or some other approach to prevent your SAML SSO from breaking automated processes which are not associated with any user.

bk2204
  • 64,793
  • 6
  • 84
  • 100
  • Thanks for your thoughtful answer. I fully agree that this wouldn't work on headless systems and should've mentioned this in the question. I'll see if the folks over at Microsofts git credential manager have this on their roadmap. – Daniel Lenz Nov 07 '20 at 20:58
  • SAML ECP-Profile is meant to be used for non-browser SAML clients. `git`client would have to implement this (and IdP needs to suppor it) – Bernhard Thalmayr Nov 09 '20 at 08:54
  • Git is unlikely to support that in the near future, even if an straightforward shared library were available. Requiring every program using HTTP to speak SAML, OAuth 2, or various other authentication protocols isn't reasonable. – bk2204 Nov 09 '20 at 23:36