principal aliases for non-LDAP backends?

[Marcus Watts]

> Date:    Thu, 18 Feb 2010 13:34:35 EST
> To:      Tim Mooney <Tim.Mooney at ndsu.edu>
> cc:      "krbdev at mit.edu" <krbdev at MIT.EDU>
> From:    Greg Hudson <ghudson at MIT.EDU>
> Subject: Re: principal aliases for non-LDAP backends?
> 
> On Thu, 2010-02-18 at 13:12 -0500, Tim Mooney wrote:
> > I know that principal aliases are currently only supported with the
> > LDAP backend.  Are there any plans to add support for principal aliases
> > with the traditional backend?
> 
> That's unclear.  When I initially proposed adding alias support, I was
> going to do it for the BDB back end only, but the feedback I got was
> that people using this feature would probably (1) want to be able to do
> bulk updates of alias information rather than going through kadmind, and
> (2) might be more likely to be using the LDAP back end since they're
> more likely to be integrating with outside sources of information.  I
> wasn't able to come up with a satisfying and easy design for (1) with
> the BDB back end.  A notable obstacle is that all accesses to krb5 BDB
> back end databases have to go through custom locking code, since the way
> we use BDB does not allow for concurrent access.
> 
> What we would like to do in the medium term--perhaps for 1.9 if we can
> allocate the resources--is create a new embedded back end, probably
> using SQLite, which is more easily extensible and which can better
> support integration with other data sources via external tools.  Then we
> could deprecate the BDB back end in favor of the new back end.  If we do
> this, it will make more sense to add support for aliases and similar
> features (such as referrals and canonicalization of UPNs) to the new
> back end.
...

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.

I don't have a problem with adding sqlite as an additional type of
repository - but I don't think it will always be the best choice.
I'm currently looking at heimdal which added "Support for new
sqlite based credential cache".  This causes application integration
problems, since sqlite wants pretty badly to use pthreads, and that's
not always good.

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.  That's definitely not
how things work at umich.  Most of the things here that interact with
kerberos do so not in a "batch processing" environment run on the kdc,
but instead run on demand, usually processing one user at a time.  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.

				-Marcus Watts