Implementing preauthentication using loadable modules

Jim Rees rees at umich.edu
Fri Sep 29 15:59:14 EDT 2006


My client plugin interface essentially just adds entries to the pa_types
table.  The ftable contains a list of pa_types_t entries, each of which has
a INFO/REAL flag, a preauth type, and a preauth procedure pointer.

The only advantage to mine is that different preauths can have different
flags.  I don't know how useful that is.

You probably also should have a version number field.

Here's my ftable:

typedef struct _pa_types_t {
    krb5_preauthtype type;
    pa_function fct;
    int flags;
} pa_types_t;

typedef struct krb5plugin_client_preauth_ftable {
    int version;
    char *name;
    char *vendor_info;
    pa_types_t **pa_list;
    int pa_listlen;
    krb5_error_code (*init_library)(krb5_context, void **);
    void (*fini_library)(void *);
} krb5plugin_client_preauth_ftable;

I think the tricky part will be deciding on the arguments to the functions.
As Sam points out, the pkinit plugin probably wants the full request body.
And the next guy who writes a plugin will want something else we didn't
think of.  Maybe they should even be extensible structs so we can add
arguments later (with a version bump of course).



More information about the krbdev mailing list