KLL as a cross-platform API

[Nicolas Williams]

After a quick glance I have the following comments:

 - All these functions need a KLL context argument.

 - On some platforms one may want to have some control over prompting
   (on a tty, on a given screen of a given X11 display, etc...).

 - I'd like a better abstraction than "outCredCacheName."

   This is really important.  How do I turn a outCredCacheName into a
   GSS credential?

   If we can make the assumption that GSS credential stores for the
   Kebreros V mechanism and krb5 ccaches are matched/interchangeable,
   then why not just output a gss_cred_id_t instead of a string and use
   GSS_Store_cred() to copy the given credential to a "current" krb5
   ccache?  This leaves the matter of how to manipulate a process'
   current cred store as the only non-generic matter (but I've made a
   proposal about that too).

   This is crossing over into CAT WG/KITTEN BoF matters.  Before you
   comment on this you may want to read the posts on the CAT WG mailing
   list archive for the last few weeks.

 - Similarly with keytabs.  I'd rather use gss_cred_id_t's instead of
   keytab names.

 - The last two comments amount to this: I'd rather see this API be a
   mechanism-specific extension to the GSS-API than a platform-specific
   interface with no tie to the GSS-API.

 - KLL seems like it could be extended so as to replace all of the krb5
   API...

Nico
-- 

On Tue, Apr 06, 2004 at 03:48:17PM -0400, Sam Hartman wrote:
> 
> 
> KFM has had an API called the Kerberos Login Library for a while.  It
> makes it easy to get credentials and to manipulate these credentials.
> It's even documented; take a look at
> http://web.mit.edu/macdev/KfM/KerberosFramework/KerberosLogin/Documentation/API.html.
> 
> 
> Alexis is working on revisions to this API for the next version of
> KFM.  The primary purpose of the revisions is to make KLL thread safe.
> 
> 
> Jeffrey Altman wants a future version of KFW to support KLL.  I think
> everyone on the team realizes that krb5_get_init_creds is not the
> paragon of user-friendly APIs.  I think it is better than
> krb5_get_in_tkt, but an even higher level API would be nice for users.
> 
> 
> If KLL is going to remain a KFM-specific API then I don't think this
> list needs to consider it much.  It is already meeting the needs of
> the KFM user community.
> 
> However if we are going to have similar APIs for all our platforms to
> do this sort of initial credentials management then it should be
> consistent across platforms.
> 
> Here are my thoughts on KLL as a cross-platform API.  It's not clear
> that we have time or desire to implement these comments.  They are
> being submitted to start discussion.  One thing that would be
> particularly useful to us would be feedback from vendors like Sun,
> Redhat and KFW about the suitability of KLL as a cross-platform API.
> 
> 			       Comments
> 
> I suspect the most controversial decision in KLL is its identifier
> name style.  IT uses studlycaps rather than lower case with
> underscores.  That's desirable for KFM because it is more consistent
> with Mac APIs.  However the krb5 and krb4 APIs tend to use
> underscores.  How confused will programmers be by having two different
> styles of API in the same product?  Would consistency between KLL and
> say GSSAPI affect vendors' decisions on whether to support the API?
> 
> Similarly, because of the Mac's Pascal roots, functions to get rid of
> resources are called Dispose not Free or Destroy.  I don't think this
> is a particularly big deal; does anyone?
> 
> 
> 
> KLL uses enumerated types for constants.  It does so in a manner
> fairly consistent with the direction we are moving for krb5.
> Anonymous enumerations are used for constants, but enumeration types
> are not part of the ABI.  One thing it does do that the krb5 code does
> not currently do is use character constants for option names.  Here's
> an example:
> 
> enum {
> /* Initial values and ranges */
> loginOption_LoginName                  = 'name',
> loginOption_LoginInstance              = 'inst',
> 
> loginOption_ShowOptions                = 'sopt',
> 
> 
> IN particular, this requires that the enumeration type be at least as
> wide as 4 chars.  Do we think this will ever be a problem?
> 
> Currently, KLL only supports API: ccache types.  Alexis said she will
> add support for file credential caches in her current work.
> Presumably on Windows we'd need support for MSLSA caches at least for
> some functions.
> 
> KLL seems to have dialogue and event loop support at least for OS9.  I
> doubt this will ever be portable across platforms; we probably have to
> accept that each platform needs its own event loop code.  
> 
> _______________________________________________
> krbdev mailing list             krbdev at mit.edu
> https://mailman.mit.edu/mailman/listinfo/krbdev