Extensible kadm5 policies

[Greg Hudson]

On 11/01/2011 11:11 AM, Nico Williams wrote:
> But I do have a good reason for this, courtesy of Jeff: not all
> Kerberos realms will be enforcing a corporate policy, but rather a
> user policy.  Consider a commercial Kerberos realm, or a commercial
> service that uses Kerberos for authentication, including having a
> realm for its users (or some of them).  Why wouldn't the service
> operator want to allow users to be more paranoid than the service
> operator is?  Why wouldn't the service operator at least want this
> option?

If I were designing from scratch, and I wanted to accommodate this, I'd
design for it by saying that each principal has an associated policy
which is initially empty (or null/created on demand).  Then the admin UI
would have a way of referring to a principal policy as well as a named
group policy.  That way all of the policy fields are semantically
contained within the appropriate object, but the group policy namespace
doesn't get proliferation.

Alternatively, I might decide that this use case isn't very
compelling--that is, if you're running a very heterogeneous realm,
policy proliferation is a reasonable price to pay for that.

Of course, we aren't designing from scratch, and we already have policy
fields in principals, so the above is mostly a mental exercise in where
we might want to end up down the road if we think we can get there.

(Realistically, it's more likely that a user would have a business need
to be *less* paranoid than the service operator is.  For instance, a
user might need to run month-long jobs or something, and need a longer
ticket life.  If we do policy inheritance or multiple policies, we'll
need to decide whether the accumulator semantics accommodate this.)

> Sure.  I think what we could do is add per-field type accessor
> "methods".  We could leave the existing C structs mostly the same, so
> as to help preserve source compatibility for a short while to help
> developers transition -- or not, but hopefully we could make this the
> last time we break the kadm5 API/ABI.

When we added principal string attributes for 1.10, we decided to
abandon the unitary get_principal/set_principal architecture and just
define new RPCs to get and set string attributes.

It might be reasonable to (a) decide on what general policy extension
framework we want (tl-data, string attributes, both, something else),
and (b) define new RPCs to set and get policy extensions.  We wouldn't
need to completely migrate away from the blobby architecture at this time.

As for making this the last time we break the kadm5 API/ABI, we very
explicitly have not committed to keeping it stable and do not want to
make that commitment in its current form.  We didn't install
kadm5/admin.h at all until 1.7, and we started doing so with the
documented understanding that it wouldn't be considered a stable API.
If we see a lot of pressure to treat it as stable, we'll treat that as a
lesson that we should never have installed it until we were more
comfortable with it.

> Supposing that I couldn't think of a good reason for it, there's still
> the fact that someone else might,

This is getting a little far afield, but philosophically I'm opposed to
this kind of reasoning.  A lot of Kerberos's complexity comes from
designing facilities nobody had a present need for.  Design for
extensibility, yes, but not for unneeded generality.