advice on kerberizing products

[Ken Hornstein]

>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