Plug-in interfaces & internal APIs

[Greg Hudson]

On 05/16/2015 02:14 AM, Ken Hornstein wrote:
> I know that doing your own PKINIT plugin requires a lot of internal
> interfaces and changing that is hard.

If you have another way of doing ASN.1 (such as asn1c), you could
implement PKINIT without internal interfaces, in principle.

Of course, if you want to copy and modify the existing PKINIT module,
our use of internal interfaces for ASN.1 (and possibly other things) is
prohibitive.  The only really practical solution is to fork the whole
tree, modify it, build it, and install only the PKINIT module.  We'd
rather it not be necessary to modify PKINIT, and I think we've discussed
what is required for that for your case and just haven't done the work.

> The biggest issue is configuration; most of the plugins require some KDC-wide
> configuration (e.g.: Yubikey requires a few parameters, like the URL for
> the validation server, a client identifier, an API key, etc etc).  Right
> now you have to call the internal profile APIs to get stuff out of krb5.conf
> or kdc.conf.  This makes me wonder exactly what people's thoughts were in
> terms of plugin configuration (it may be that this was never considered).

You can call krb5_get_profile(), profile_get_*(), and profile_release().
 Those are all public libkrb5 APIs.  Avoid using the krb5_appdefault_*()
interfaces; they are pretty broken.

Heimdal has krb5_config_get_*() interfaces, which I think is a cleaner
solution, but we wouldn't get a lot of benefit out of implementing them
since we're stuck supporting the profile APIs indefinitely.

> The second thing I've run into is storing per-principal information.
> I know about the set_strings/get_strings interface; we use that, and
> it's great!  But we have some cases where the plugin needs to modify
> some data associated with the principal, and there is no set_strings
> interface.  I know there's a callback to retrieve the principal record,
> but I was wondering if that's the preferred method for storing stuff,
> or if there should be an additional callback to store string data
> (or TL_DATA) on a per-principal bases.

For the moment, using the client_entry callback and libkdb5 is the only
way to do this.

We could consider adding a set_string callback, but it would raise
architectural issues.  The KDC was originally a read-only consumer of
the KDB, unless built with KRBCONF_KDC_MODIFIES_KDB.  We changed that
(conditionally) when we implemented account lockout, but that change
hasn't been consequence-free for performance and concurrency behavior.
It might have been better--although much more difficult--if we had
implemented a second, non-replicated database for ephemeral principal
data such as lockout counters.