kadmind authorization design choices

[Simo Sorce]

On Tue, 2017-06-13 at 13:36 -0400, Greg Hudson wrote:
> 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.

I do not think moving to libkadm5srv is that compelling.

> 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.

They can always use kadmin even when operating on the local host, so I
am not sure how useful it is to have to fake things in kadmin.local ...
can't really judge w/o hearing the reasons for such "emulation".

> 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

I prefer this one for implementation purposes as it allows to break
things in smaller steps and test each function independently.

> * 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.

I think it is also a matetr of readability and better debuggability.
for example in gdb catching a specific function w/o having to manually
waive "other uses" can be really useful if you want to step into a
specific authz step in a process that is going through many steps.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc