kadmind authorization design choices

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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.
_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: kadmind authorization design choices

Simo Sorce-3
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


_______________________________________________
krbdev mailing list             [hidden email]
https://mailman.mit.edu/mailman/listinfo/krbdev
Loading...