[Nicolas Williams <Nicolas.Williams@sun.com>] client-side pre-auth re-architecting
Nicolas.Williams at sun.com
Tue Dec 31 16:26:01 EST 2002
On Mon, Dec 30, 2002 at 04:46:31PM -0500, Ken Hornstein wrote:
> > - a generic mechanism is needed for setting mech-specific pre-auth
> > options via a get_init_creds options (say,
> > krb5_get_init_creds_opt_set_preauth_opt())
> > [hartmans] Originally I thought that you could just have
> > functions like krb5_gic_opt_set_hwauth_keytab. Nico pointed out
> > this style does not work well if we have plugins for preauth
> > modules. He indicated that might be important to him in the
> > future.
> I hadn't thought about plugins for preauth modules, but that would be
> cool. Defining the right plugin API for this seems ... challenging, I
> will admit, but that comes later :-)
Think pam_set_data(). Something like krb5_gic_opt_set_pa_data(), using
a char string to name a datum, with a naming convention of prefixing
data names with "<pre-auth name>_" and a (void *) parameter for the
This way krb5.h, preauth2.c and gic_opt.c need never be updated when
adding pre-auth types - instead you can add a per-pre-auth mech header
for pre-auth mechs with private C types. The application will have to
know the datum names and types, but that's no big deal - nor would the
apps have to do anything special for PA-ENC-TIMESTAMP; and PA-TGS-REQ
would have only two parameters, with default values: a princ name and a
keytab name. Similarly with your hw pre-auth type.
> > - some arguments of pa_function can move into the gic context since the
> > pa_functions can then get them from there (e.g., the
> > gak_fct/gak_data)
> Seems logical.
gak_fct should be called once and then its result memoized (a macro
for this would be handy).
More information about the krbdev