dpotapov / go-spnego

Wraps gokrb5 and sspi libraries to provide cross-platform way to make HTTP calls with Kerberos authentication

go-spnego

The package extends Go's HTTP Transport allowing Kerberos authentication through Negotiate mechanism (see RFC4559).

Internally it is implemented by wrapping 2 libraries: gokrb5 on Linux and sspi on Windows.

There is no pre-authenticaion yet, so the library assumes you have Kerberos ticket obtained.

Linux implementation requires MIT or Heimdal Kerberos to be present. Windows implementation utilizes credentials of currently logged in user.

Currently it allows only to make HTTP calls, no server side support yet.

Installation

go get github.com/dpotapov/go-spnego

Usage example

import "github.com/dpotapov/go-spnego"
...
c := &http.Client{
    Transport: &spnego.Transport{},
}

resp, err := c.Get("http://kerberized.service.com/")

Configuration

Windows: no configuration options.

Linux:

• KRB5_CONFIG - path to configuration file in MIT Kerberos format. Default is /etc/krb5.conf.
• KRB5CCNAME - path to credential cache in the form type:residual. Only FILE: type is supported. Default is FILE:/tmp/krb5cc_$(id -u)

go-spnego's Issues

Package attempts to authenticate every HTTP request, even if Kerberos is not supported

The title probably seems antithetical to the purpose of this package, so bear with me for a moment. 😄

When adding this package's Transport/RoundTripper, it immediately sets a Kerberos token on all requests that pass through it.

This causes two problems:

• If a host does not [currently] support Kerberos, the package will attempt to generate a Kerberos token anyways
• If the client has composed multiple auth-related transports/RoundTrippers together, stamping tokens on every request means other transports can't authenticate.

In my case, I'm writing a client for a service that's currently NTLM-only (WWW-Authenticate: NTLM - yeah, I know, it's old) with plans to enable Kerberos auth in the next couple of months. To make my life easier, my plan for the client was to compose an NTLMSSP transport (similar implementation to Azure/go-ntlmssp's Negotiator), with this as the inner transport.

By comparison, Azure/go-ntlmssp takes a more conservative [multi-step] approach to authentication - requests are tried in the following order:

• As-is, from the parent transport
• Without any authentication, (if and only if the previous request had any)
• With an NTLMSSP_NEGOTIATE message, if either of the previous two requests declared WWW-Authenticate: NTLM
• With an NTLMSSP_AUTH message, if the previous message provided an NTLMSSP_CHALLENGE message

Not all of this is directly applicable to SPNEGO, but this does have the benefit of:

• Not munging requests unless absolutely necessary (thus allowing other auth methods from outer transports to work)
• Not performing unnecessary authentication work against a service that doesn't accept Negotiate auth

Happy to PR something to adjust this if desired - this should also be something that can be configured (maybe a bool flag like ForceAuthentication defaulted to false, like #5 did)

Consider updating to a newer version of gokrb5

The version of gopkg.in/jcmturner/gokrb5.v5 used here doesn't contain go.sum entries for all its values and consequently it can't be built with Go 1.16. Is it possible you could update to v8 so that folks can use this on Go 1.16?

Building for OSX gives "undefined: New" error

Quite literally the title. Can't figure this one out, but if you build for OSX (so.. darwin / amd64) the following error occurs:

../../go/src/github.com/dpotapov/go-spnego/transport.go:24:14: undefined: New

I assume there's something hardcoded that needs to be updated but I don't know where it is.

SPN discovery gets wrong service when it does not first attempt accessing the SPN for the given hostname rather than immediately doing a reverse lookup.

I was working through an issue in GitLFS that traced down to an apparently errant behavior in spnego. On Windows, in the spnego_windows.go file, the SetSPNEGOHeader attempts to form a Canonicalized hostname from the given URL's hostname without ever trying the given host. In any environment with multiple services on a given IP, this could result in an incorrect SPN being chosen. This canonicalization is a good attempt at recovering from an SPN missing for a service, but causes intermittent incorrect SPN selection when the given host is valid and multiple hosts share an IP address.