You are viewing the Kantega SSO legacy documentation. The new documentation site is:
Skip to end of metadata
Go to start of metadata

Kantega SSO adds the ability of cloning from HTTP using Kerberos authentication. This way, users can clone and push their code without having to type their password, and without managing SSH keys.


Not all Git clients support Kerberos. Git client which do not support clients will often not be able to understand the Kerberos-related HTTP headers, and will simply fail to communicate with a Kerberos-enabled Git HTTP server. We do support only Kerberos over the HTTP/HTTPS protocol, not over SSH. Also the GIT LFS protocol does not support Kerberos at all.


Because of the limitations described above, Kerberos support in Kantega SSO is a completely optional feature which the users can opt-in to by using an alternative HTTP URL when cloning with Git.

This way, the cloning experience for non-Kerberos clients is unaffected by the Kerberos feature.

When this feature is enabled, the users will find "HTTP+SSO" as an additional URL to clone from in the Bitbucket clone UI:

Bitbucket admins can decide if the HTTP+SSO should be set as the default.

Kerberos supporting Git clients

Most clients based on the stock git client, or clients using libcurl for their HTTP implementation should work.

Some clients which are known to have worked in some version:

  • The native Git command line client
  • IntelliJ IDEA
  • Eclipse 

Git clients newer than 2.10.2

From Git 2.10.2, authentication without explicit username and password is no longer enabled by default.

To re-enable support for Kerberos, you need to set the "http.emptyAuth" config switch to true.

This can be done for a single invocation, like this:

git -c http.emptyAuth true clone <URL>	

Or you can set it up once as a global config:

git config --global http.emptyAuth true

  • No labels