>It is also worth mentioning that GSS-API is closer to being portable >than native Kerberos APIs, and you should use GSS as much as possible to >avoid some interoperability issues. It also makes your coding a lot easier.
I call "bullshit" on these two statements. For a SIMPLE program, your first statement is perhaps true. But I find that, for example, MIT and Heimdal have a number of slightly different API extensions. And I see a number of GSSAPI programs that have to do some magic to determine which GSSAPI library that they are using. And coding a lot easier? I cannot imagine any universe where that is a true statement. I've written both - the Kerberos code is smaller and simpler, there is simply no comparison. Now, on the documentation front I will admit that GSSAPI has an edge; the RFC actually isn't too bad as documentation. But I find the abundant Kerberos examples to be fine in that regard, and I am guessing that Kris didn't have a problem from that standpoint since he already has working code. I make no bones about not being a huge fan of the GSSAPI, and I freely admit that I'm in the minority. I use it when it is appropriate (basically, when I need to interoperate with a protocol that has been standardized to use it), but when I write something for myself I always find the Kerberos API simpler and more versatile. A few other comments, based on what other people said: - To be fair, like Simon pointed out, if all you need is the basic GSSAPI functionality then from a portability standpoint the GSSAPI is probably better. But if you were Kerberizing something like ... oh, I don't know, let's say a backup system, I would bet that you will quickly find that you want to do things that you cannot do via GSSAPI. It's my understanding that Thunderbird and Firefox use dlopen() or the equivalent to load the GSSAPI libraries, which would make then basically option 1, except with the GSSAPI. I think in terms of portability you'll need to do that anyway, since I doubt that the GSSAPI library versions are the same across Heimdal and MIT. But I will note that in the case of Thunderbird and Firefox GSSAPI was the only choice, since the whole point of adding Kerberos support to those programs was to support protocols that used the GSSAPI. Well, I suppose Simon could have generated GSSAPI tokens using raw Kerberos calls and a lot of bit-fiddling, but even I'm not that crazy :-) - The two major open-source Kerberos implementations include GSSAPI libraries. In theory, depending on who you talk to, there are a billion different GSSAPI mechanisms and you have to make sure your code can handle non-Kerberos mechanisms. In practice, however, you can basically consider GSSAPI as "the other" Kerberos API. - While Jeff suggests that you use SASL ... I actually would not. There is basically only one widely-supported open-source SASL library, and that means you're moving your support issues from Kerberos or GSSAPI into the SASL library. You can always write your own SASL layer on top of the GSSAPI library ... but I've done that, and that is no fun either. --Ken ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
