Extensible kadm5 policies

[Tom Yu]

Nico Williams <nico at cryptonector.com> writes:

> The type overloading in the kadm5 API based on the version
> identifier supplied by the caller is certainly ugly.

I believe we removed the worst of this "type punning" in krb5-1.8,
when we deleted support for the old OpenVision admin protocol (which
was deprecated even when we first integrated it).

>  - Do we want any policy fields to also be fields of principals?  Why/why not?

No.  Too much policy information is already stored on a per-principal
basis that should never have been stored there.  For example, I've
seen many queries about "why can't I increase the max ticket
lifetime?", which tend ultimately to reflect the inflexibility of
per-principal ticket policy settings.  (Globally increasing the max
ticket lifetime requires editing every principal in the database.)

>  - Do we want extensible policies at all?

Probably, even though we should manage it carefully.

>  - Do we want to add a new kadm5 API version and overload the C types
> one more time?  Do note the need to do the same in the protocol, or to
> add new RPCs.

I'd like to see us move to an approach that better abstracts
operations on principals and policies.  Currently, API users must deal
with the entire structure (principal or policy) all at once, whether
or not they need to.  (It might not necessarily be completely filled
in.)  Some people refer to this as the interface being too "blobby".
I believe it's a result of revealing too many of the implementation
details of how we store the information in a simple key-value databse,
instead of designing an interface that would be easy to use.

> I must say that I'm not too upset by the idea of adding a new kadm5
> API version and doign more type overloading *in MIT krb5*.  It would
> never happen in Heimdal, but we can break kadm5 ABI there, so that's
> not a big deal.  But for the db2 backend I'd still propose
> policies-as-principals just so we can get policy iprop.

We make far weaker stability assurances for the admin API than we do
for the krb5 API.  Where I do want to try to maintain backward
compatibility is in the protocol.