Uncomplete context case?

[Geobert]

According to https://datatracker.ietf.org/doc/html/rfc4559#section-5

If the context is not complete, the server will respond with a 401 status
code with a WWW-Authenticate header containing the gssapi-data.

But when we call accept(), if I read the code properly, there's no Error managing this case. It's either we are good or not with the provided token.

Am I reading right?

If yes, maybe there is something to do around windows.rs:572-577 ?

EDIT: Maybe we need a proper error type instead of an anyhow::Error so we can match against it for different errors causes and manage the SEC_E_INCOMPLETE_MESSAGE case?

[estokes]

It was probably a mistake to add that flag. The thing is this library is able to be simple because it is focused on using Kerberos cross platform, however what you're trying to do is use SPNEGO, which is an entirely different GSSAPI mechanism. My understanding is that SPNEGO could result in both sides needing to exchange an arbitrary number of tokens, and negotiating the use of any mechanism supported by gssapi (or sspi in your case). Quite likely your application is actually using ntlm, or certificates, or who knows what.

The point I'm trying to make is, if I tried to build a cross platform high level interface to gssapi/sspi it wouldn't be simple, and the corner cases and bugs I would likely hit are honestly terrifying. IMHO gssapi and sspi should never have existed in the first place, they are trying to make things that aren't remotely similar accessible by one interface.

Rants aside, I'm not sure I want to embark on trying to wrap both these complex beasties up in a high level easy to use library. I will give it some thought. In the mean time I think your best bet is to use the code in windows.rs as an example of how your application can use SSPI to authenticate a web client. You will likely need to generalize it to exchange however many tokens the underling mechanism you are actually using wants to exchange, but it otherwise should be mostly what you want.

[estokes]

Hi @Geobert, it seems I was wrong, while debugging channel bindings I found that I had oversimplified the api even for Kerberos. I had thought that the Kerberos mechanism would always resolve after 1 client token and 1 server token, but unfortunately that isn't the case. Specifically when something goes wrong, multiple tokens need to be exchanged in order to get a readable explanation of what happened, and there might be other cases as well.

I've reworked the api to allow exchanging an arbitrary number of tokens, and I wonder if that will fix your problem.

[Geobert]

Hi, thanks for the heads up, but we've forked the windows.rs and I've customized it to fit our needs (removed parameters here and there, etc.) and reached a staged where it fulfills our needs.

I'll keep you posted if we decide to switch back to your crate :)