SEAM krb API

[Ken Hornstein]

>>FWIW, everyone I know who does Kerberos stuff on Solaris systems doesn't
>>use SEAM, they use one of the third-party Kerberos implementations and
>>link against that.
>
>OW! Ken, that hurts :).  Anecdotal evidence is highly subjective, obviously.

Oh, without a doubt.  Obviously I don't know everyone out there who uses
Kerberos on Solaris, or even a majority of them.  I hope everyone understood
I was only offering the solution to the original poster's problem that was
most common to me.

>Also, SEAM also includes
>Kerberos protection for NFS which is not available with 3rd party
>implementations and is an attractive feature in some circles.

Actually ... I was able to get this going without having to use SEAM.
All that was necessary was to give the credential cache the right name,
and it all magically worked.

>We have not found alot of customers that really need direct access to 
>the KRB5 APIs.   Usually showing them how to use PAM or GSSAPI is sufficient.

Hm.  I have never actually seen a GSSAPI server program that didn't
also require calls to the krb5 API as well (we make heavy use of
cross-realm, so we always need to call krb5_kuserok(), and then there
is the whole credential cache management issue as well).  I admit that
on the client, it's usually not necessary.  I suppose that it might be
possible to possibly use PAM in place of krb5_kuserok() (I am not sure
this is true, but let's pretend that it is), but considering that PAM
has relatively poor OS coverage I'd have to maintain two sets of code
(one PAM, one krb5 API).  For me, the added headache of supporting two
sets of code isn't worth transitioning to a vendor-supplied Kerberos;
it's easier for me to just use the one I compile.

For example, I was trying to help someone once who was trying to get
Simon Wilkinson's GSSAPI patch for SSH going with Solaris & SEAM, and
he ran into the problem that Solaris didn't export the krb5 API.  He
asked what I did, and I had to tell him that I didn't use SEAM, and
that I advised him to do the same thing that I did (use the MIT
library).

Yeah, I know that krb5_kuserok() isn't exactly the best thing in terms
of authorization, but we developed a whole infrastructure based on it,
so we're stuck with it for now.  And I know that credential management
is progressing in the GSSAPI space, but it's not reasonable to ask me
to delay software rollouts for the API design & implementation to finish
when I have what I consider a reasonable solution in the krb5 API.

>The original reason we did not expose the Kerberos API was that it was
>non-standard and we didn't want to have to end up supporting old APIs
>for years to come.  I realize the API situation has stabilized somewhat
>in recent years but when the Solaris 8 SEAM packages were made, this
>was not the case.

I certainly understand the reasoning ... it's just that that a lot of
the programs I need to use still require the use of the krb5 API, so
SEAM isn't an option for me and others.

>We have made alot of big improvements in the past couple of years.
>Many of our new features can be previewed now in the Solaris Express 
>release. 
>SEAM is no longer unbundled, Kerberos support is fully integrated, crypto
>support is up-to-date, SPNEGO has been added as a GSSAPI provider, and we
>have some new  innovative features like incremental database propogation.

Those all are pretty cool; now if there was just krb5 API support, I might
even be able to use it :-)

--Ken