Git CLI verification via SAML SSO

user_4874233 0
Viewed 2486

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

gitlab azure saml single-sign-on git
1 Answers

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.

user_87054320
Related