advice on kerberizing products
Ken Hornstein
kenh at cmf.nrl.navy.mil
Wed Apr 23 21:19:43 EDT 2008
>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
More information about the Kerberos
mailing list