Kantega SSO adds the ability to clone 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.
In the Kerberos configuration of the Kantega SSO Enterprise app, you find a page called Kerberos for Git. Users will find the cloning protocol option "HTTP + SSO" when this feature is enabled. Bitbucket admins can decide if the HTTP+SSO should be set as 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 who are known to have worked in some version:
The native Git command-line client
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
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 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.
If you are setting up Kerberos for Git and want to use a CNAME as your hostname of Bitbucket, please note the following: While browsers are using the CNAME for looking up the A record and uses this when requesting a Kerberos ticket, your Git client will not. The Git client will request a Kerberos ticket using the CNAME. Therefore, when using Kerberos for Git in combination with using a CNAME, you will have to create a merged keytab in K-SSO consisting of one keytab for the A record and one for the CNAME. Please contact us if you have any questions about this setup.