Add SSPI implementation

[TheJayMann]

Would this be the correct place to ask for an SSPI implementation when built for Windows? Or would it be more appropriate an SSPI implementation be it's own separate plugin? SSPI allows Windows applications to use Kerberos authentication both on the client as well as on the service without having to manage a keytab file and without having to set up a connection to an LDAP server.

If this would not be appropriate for this project, this issue can be closed with said explanation, and, if so, I may attempt to create the plugin myself.

[tyrannosaurus-becks]

Hi! This is a great place to open the feature request.

We've been using the jcmturner/gokrb5 library and from these two issues, it looks like it might support this workflow.

• [Question] HTTP SPNEGO Authentication after kinit jcmturner/gokrb5#328
• question: cross-realm support jcmturner/gokrb5#130

This is our first time receiving a request for this feature, so I wouldn't expect it to be on our near-term roadmap. So, you'd be welcome to either fork this library and add it, or PR it into this one, or just create a new plugin, whatever works best for you.

If you PR'd it in, we'd very much appreciate it. To accept a PR, we'd need:

• The new code to be 100% backwards-compatible without any configuration changes on the part of current users.
• End-to-end tests that cover the code's expected use case.

For now, I'm going to mark this PR as "Help Wanted" to signal that we're open to a PR like this. Thank you for your inquiry!

[TheJayMann]

After further research, from what I understand, gokrb5 itself does not implement or wrap SSPI. From the two issues linked, gokrb5 is rather being compared to SSPI at a high level. Also, concerning configuration, a proper SSPI plugin implementation would have no configuration. By using Windows functions such as AcquireCredentialsHandle, AcceptSecurityContext, QueryContextAttributes, GetTokenInformation, and LookupAccountSid, authentication and group member lookup can be accomplished with no provided configuration. While configuration compatibility can be maintained by having all other configuration ignored if the plugin is configured to use SSPI, it appears to me that the code and configuration shared between the gokrb5 implementation and the SSPI implementation would be little to none, not quite justifying them being shared in a single plugin.

Given this, I'm of the mind that an SSPI implementation should be its own separate plugin, also because, in addition to kerberos, SSPI also implements NTLM, CredSSP, Digest, and Schannel authentication. Such a plugin would probably make use of the https://github.com/quasoft/websspi middleware, either as a dependency, or as a starting point.

If you believe otherwise that an SSPI implementation would be better implemented as part of the kerberos plugin, feel free to reopen this issue, and I'll see about how such an implementation can be included in the plugin. Otherwise, I believe I will see what it takes to start writing a stand alone implementation.