Securing git (via HTTPS) with Keycloak

Securing applications
1

Hi All,

I’ve got a use case that I haven’t run across before. I’d like to secure git (via https) using keycloak.

A few additional requirements:

  • The keycloak setup is one where there may be external IdPs, so password and client_credentials grant types won’t work.
  • Running a local webserver that listens for the callback is considered a “security hole” by the customer, since it would either need to run on http, or with a self-signed cert.
  • We can install git “credential helpers”.
  • We have full control over the proxy in front of git (nginx), and can modify its configuration and modules.

My initial thought was the following:

  • Write a git “credential helper” that outputs a login link to be opened in the browser
  • Have the login use a client with a custom login flow
  • Write a custom authenticator that stores a “code” (e.g. 6 digits or something simple) as a new credential type, and outputs the code at the end of a successful login
  • Use the git credential helper to ask for the code
  • Write the nginx configuration using the auth_request module to perform an auth subrequest that passes the code to keycloak, which returns a 2xx, and deletes the credential if it matches (to enforce one-time use)

My questions are:

  • Has anyone encountered a use case like this?
  • Can anyone review my proposal and see if there are holes/improvements?

Thanks and best regards!

2

It sounds like a code which needs to be maintained and also deployed to the user. I tested https clone in one enterprise GitHub with SAML SSO enabled:

remote: Password authentication is not available for Git operations.
remote: You must use a personal access token or SSH key.

Quick google and I found that Bitbucket has similar approach. So I wouldn’t introduce bespoke authentication.

If it is really necessary then proposed approach seems to be OK. It is similar to CloudFoundry CLI sso login cf login --sso - cf will provide a url to obtain a one-time passcode to login. I would think about race conditions: e.g. two auth requests are initialized at the same time.

I would introduce also limited time validity of the stored code - user may not exchange code for the code, so permanently stored code will increase attack surface and 6 digits code without time expiration is really weak for brute force attack.

Passcode with good entropy will be even better instead of the 6 digits code - otherwise there is attack window when slow human will try to copy code from the browser to the git cli - attacker with fast paralelized brute force power has a good chance to guess that 6 digits and got a token first.

1 Like