Extensible kadm5 policies

[Nico Williams]

On Sun, Oct 30, 2011 at 11:23 PM, Greg Hudson <ghudson at mit.edu> wrote:
> What I like about this proposal:
>
> * Many of the fields in principal entries are ticket policy fields and
> belong more properly in a (currently nonexistent) ticket policy object.
>  This proposal more or less rectifies that mistake.

More generally I can't think of any great reason why policy fields
couldn't also be principal fields.  If there are any policy fields
with high rate of variance then that would lead to a proliferation of
policies.  OTOH, if no policy fields have high variance then I think
sysadmins would (should, IMO) prefer that all policy fields not be
fields of the principal.

I doubt policy fields will have high variance in general, so that
argues against my proposal.  Aside from this, I do think it's elegant
to model principals and policies as having a common class from which
to inherit all those fields of policies that can properly be fields of
principals (which aside from the policy name, should be most of them).
 But I can't ignore this argument about the propriety of having
low-variance policy fields in principals -- alone it seems
insufficient to rule out this design, but it does weaken arguments for
it.

>[...]
> What I dislike or am nervous about:
>
> * In order to actually get rid of the .kadm5 database, we need to force
> a dump and load at upgrade time for the DB2 back end.  Our upgrade
> instructions have always recommended this, but I don't know that we've
> actually required it in any release since at least 1.2, so admins might
> find it disruptive or surprising.  Maybe not a big deal.  We'd need a
> safety mechanism to make sure that a dump and load was performed
> (otherwise the KDC appears to work but policies aren't enforced, which
> is bad).

Well, it still wouldn't be required, would it?  And maybe kadmind
could do it when you first set an extended policy field?  But yeah,
that's just more code (which would have to be careful to make sure
that a mod_pol doesn't leave you in a situation where you can't
rollback to an earlier version of MIT krb5).

> * I don't know what the transition path would be for the LDAP back end.
>  It's much less reasonable to force a dump and load for LDAP upgrades.

I don't think any transition would be required for LDAP!

The reason is simple: LDAP classes are extensible, so any new policy
fields are easy to add.  The backend would have to map
policies-as-principals to/from policies in the DS, but that'd not be
hard.  If the schema is arranged so that policy attrs are also attrs
of princs then the only thing to do is to map between policy names and
the policies-as-princs well-known naming convention.

> * Representing existing policy fields as tl-data entries in kadmin would
> be a bit painful.  Maybe we could make nice wrappers for it.

Everything new has to be in TL data (or as your strings idea, also in TL DATA).

Either that or we build a replacement kadm5 protocol (possibly as new
RPCs to the existing kasm5 program).

> * We'd have to maintain two-way kadmin compatibility for a long time to
> avoid making people's lives difficult (people are slow to upgrade KDCs).
>  That's a lot of legacy code.  We'd also need legacy transition code for
> dump and load.

At least for dump and load that would be true no matter what policy
extensions we go with.

> * This might be overkill for the underlying needs.  The kadm5 policy

Sure, we could just add plugins leaving it to each site to decide how
to express and evaluate policy.  That's not a great solution, but it
wouldn't be overkill :)

> structure has been amended as recently as 1.8, abusing the handle API
> version as a structure version field.  It's very hackish but there's
> precedent for it in MIT kadmin (principal entry encoding also depended
> on handle version before kadmin v1 was removed).  Adding tl-data and/or
> string attributes to policy objects would probably not be very difficult
> and would not make the kadmin protocol substantially worse than it
> already is.

Oh, I kinda hate this overloading thing...  So I had not considered
it.  For MIT I think it'd be more sinning of a kind that's been done
before, so, it'd be tolerable.  For Heimdal?  I should talk to Love.
Heimdal only has one kadm5 API version, and Love might be willing to
break ABI compat to add things here, in which case I'd strongly
consider this.  I would hope that some day MIT can get away from this
though...

> * I have to try hard to see this as elegant.  If we were designing our
> KDC data model from scratch with no baggage, I don't think there'd be
> much justification for representing principals and policies the same
> way.  It's only because principals are already loaded with a bunch of
> ticket policy fields that it starts to look approximately as elegant as
> what we have now.

Agreed, except insofar as it might be desirable to have policy fields
in principals (which I'm less sure of now; see above).

> Some of the above points are negated by not representing policy as
> principal in the back end (kadmind could translate policy principals
> back into policies), but if we don't go all the way then this just
> becomes an ugly protocol hack with minimal benefits.

Let me think about the overloading of kadm5 idea.  And I wonder what
others think of it.

Thanks,

Nico
--