kadmind authorization design choices

[Greg Hudson]

I have started work on making kadmind authorization more flexible,
probably by adding a new pluggable interface.  The early project page is
here:

https://k5wiki.kerberos.org/wiki/Projects/kadmin_access_interface

There are two design choices I would like input on before I get too far
into this work:

1. Currently the kadm5.acl processing code lives in kadm5srv, but is
only called from kadmind.  I would like to move that code into kadmind
and make it one module within a pluggable interface consumed by kadmind.

However, a developer on IRC raised the possibility that someone invoking
kadmin.local (or another libkadm5srv application) might want to
voluntarily apply the permissions for a client principal, as it might be
performing on operation on that client's behalf.  To support this use
case, we would likely need to move the code that performs authorization
checks from kadmind into libkadm5srv, in which case having moved the
code out of libkadm5srv would seem like an error.

My question is: how important is this use case?  It would likely take a
fair amount of work to make libkadm5srv handle the authorization checks,
and if we're never going to get around to it, YAGNI applies.  But if
this is an important need that we've simply been neglecting, I'd like to
know.

2. If you were implementing a module for this new authz interface, would
you rather:

* Implement one megamethod, with an opcode (with around 15 possible
  values) and several parameters, not all of which are applicable to all
  opcodes

* Implement roughly fifteen methods, where the operation is part of the
  method name, and the parameters depend on the opcode

* Implement 3-5 methods for different classes of opcodes (e.g. principal
  operations, policy operations, and general operations), where each
  method has an opcode and parameters dependent on the opcode class

I think all of these options can be made properly extensible, so this is
mostly a matter of preference.