principal aliases for non-LDAP backends?

[Greg Hudson]

On Thu, 2010-02-18 at 14:30 -0500, Marcus Watts wrote:
> Perhaps I'm being reactionary, but I actually like the BDB backend.
> It's relatively simple, self-contained, and discourages "integration
> with other data sources" by people who don't care about security.

>From an administrator perspective, I think any good embedded back end
will be equally simple and self-contained.  Obviously I don't agree that
it's a positive for the back end to discourage integration, with or
without scare quotes.

>From an implementation perspective, the BDB back end is not simple, and
as a result is difficult to extend.  Unfortunately, a lot of its
messiness is currently exposed through the DAL.

> This causes application integration
> problems, since sqlite wants pretty badly to use pthreads, and that's
> not always good.

Can you elaborate?  The only information I can find about SQLite and
pthreads is that SQLite is thread-safe (with some restrictions) and the
developers don't like threads.

> For alias support, it sounds to me like you're proposing some sort of
> bulkload facility which runs in batch mode, eats some kind of input
> file and directly manipulates the database.

No, the design was headed more in the direction of aliases living in a
separate database which could be manipulated with standard tools.  But
the way we use BDB now, we need custom locking code to mediate access
between the KDC and other tools, which means standard tools wouldn't
work.  Plus, there don't seem to be standard BDB tools for reading and
writing individual keys, only for dumping and loading.

> Of far more value to us would be better supported programmatical
> administrative interfaces.  Various of the things here that do kadm5
> are in C, java, or perl.  For perl, a better mechanism for
> Authen::Krb5::Admin to use would be of particular interest.

Creating better APIs would be another way of enabling integration, and
would have the advantage that krb5-specific APIs can do crypto
operations.  The downside is that we have to anticipate more of what
people want to do, and that people are limited to the languages you've
created bindings for.

I think people want to be able to integrate with the back end at a data
level, or we wouldn't have an LDAP back end.  At the same time, the LDAP
back end comes with some obvious costs, driving people to continue using
the embedded back end; I just wish they didn't lose the ability to
directly view or manipulate their data when they do so.