>I have said this before on the list and it’s not a very popular thing to >say, but I program to the krb5 public API, and it is a nice and clean and >performant and simple and portable and flexible API, and GSSAPI looks like >none of those things, it looks like a mess to use (just from looking at it >for my needs, I have never programmed with it). So, I hope there isn’t >some movement to deprecate the lowlevel public krb5 API, because it is very >useful for me at least.
Dude, you are NOT the only one who feels that way, and I can't even BELIEVE people argue otherwise! Yes, the GSSAPI is a mess; there is no getting around it. The krb5 API is about 100x simpler (there are more functions, true, but most of the time you only need a handful of them). I've used both; there's just no comparison. I understand why the GSSAPI was created and the point of it and I use it when I feel it is appropriate; I understand why it is specified in protocol standards. But in the service of making it "generic" it ended up being very complicated. And if you want to have your protocol only require a single round trip, you're stuck either calling the krb5 API directly OR assuming that your GSSAPI mechanism will complete in a single round trip (the latter is what Microsoft chose for their GSSAPI HTTP protocol), which in my mind kind of negates the "g" in GSSAPI. However, one thing is worth mentioning: in my experience the GSSAPI is portable. The details of the krb5 API are basically tied to the particular Kerberos implementation you're using, and that means you're stuck either with a lot of compatibility code OR you have to compile your preferred Kerberos implementation for your target platform, which presents it's own issues. If I want a truly portable application then I do use the GSSAPI. --Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
