KLL as a cross-platform API
Nicolas.Williams at sun.com
Fri Apr 23 13:42:42 EDT 2004
On Tue, Apr 20, 2004 at 01:15:10PM -0500, Nicolas Williams wrote:
> After a quick glance I have the following comments:
> - All these functions need a KLL context argument.
This has been addressed already by Alexis and Sam.
> - 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...).
As I see it the app shouldn't have to provide prompter functions, but
it's important to be able to control the "device," if any, on which
prompting will be done.
> - 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.
Ok, forget the gss_cred_id_t notion. It suffices that, instead of
outputting a ccache name, the credential acquisition function simply
stores the acquired credential into the current credential store of the
At that point the only thing this interface needs to have added in order
to be a generic initial credential acquisition extension to the GSS-API
is this: a mechanism OID (or name, if you wish to stay away from GSS
types) argument to the KLL name import function.
More information about the krbdev