Implementing preauthentication using loadable modules g.w at
Thu Oct 5 13:41:17 EDT 2006

On Sep 30,  6:50pm, Sam Hartman wrote:
} Subject: Re: Implementing preauthentication using loadable modules

Good afternoon, hope the day is going well for everyone.

> I've thought of one other significant potential issue.
> the current plugin uses the same entry point for the KDC and client
> code.  I'm not sure this is a good ide.  Architecturally, plugins need
> to have no unresolved symbols on some platforms.  So, if you are going
> to link against the kdb or kadm5 libraries (especially if you are an
> in-tree plugin with k5-int.h access), then you will pull in a bunch of
> code not needed on a client.  Also, for many operating systems this
> code may not even always be installed on a client.
> I wonder if we want different plugin entry points and locations for
> KDC and client?

Speaking from the experience of having implemented a complete plug-in
architecture for MIT/KRB5 I can personally attest to the need to
implement separate plugins for the three major functionality
components, ie KDC, kadmin, client.

We started with a unified plugin and discarded the strategy.
Supporting intercepts for KDC and kadmin functionality extensions
drags too much dependency into the client plugin.  Building client
plugins out of tree is certainly untenable without the isolation.

Inspired by a conversation at Ann Arbor we hope to have a 'budget' two
factor authentication implementation based on intrinsic identity
injection in our next release.  Implementing client side functionality
extensions to support that quickly motivated us to isolate the plugins.

> --Sam


}-- End of excerpt from Sam Hartman

As always,

                         The Hurderos Project
         Open Identity, Service and Authorization Management

"Don't worry about people stealing your ideas.  If your ideas are any
good, you'll have to ram them down people's throats."
                                -- Howard Aiken

More information about the krbdev mailing list