Implementing preauthentication using loadable modules

[Nalin Dahyabhai]

On Fri, Sep 29, 2006 at 03:59:14PM -0400, Jim Rees wrote:
> 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.

It's probably a toss-up.  We could either have the flags be
per-mechanism, or require that mechanisms which provide different flags
be implemented as separate modules.  For PKINIT, the latter seems
sufficient.  A third option is to let libkrb5 get the client flags by
calling a callback, the way the server does.  In that case, the preauth
type would have to be passed in....

Any objections to changing so that the client flags are provided by a
callback, and to make the client and server callbacks take the preauth
type as an argument?

> You probably also should have a version number field.

The name of the symbol which the module exports is implicitly being used
for this.  It doesn't provide for major/minor versioning, though (the
module is either compatible with the library's expectations, or it
isn't).

Nalin