Open Stack

On Tue, 2013-04-30 at 23:57 +0100, Salvatore Orlando wrote:
> and we would like to say that the policy for setting enable_snat must
> be rule:admin_only.
> there are several options, among which:
> 
> 
> 1) this way of doing authZ does not make sense at all. authZ should be
> enforced on resources not single attributes
> 2) If the particular attribute comes from some specific extension,
> instead of policing access one should be allowed to turn
> administratively on/off the extension itself
> 3) We should have a rule check for sub-attributes (like FieldCheck in
> quantum/policy.py).
> 4) The enable_snat attribute should be moved to the first-level
> resource, and authZ checked as with any other attribute

When I rewrote policies into a language, one of the features I included
was a "case" syntax; the idea was that, instead of just giving you a
"authorized" vs. "unauthorized" decision, the policy enforcer could give
you finer-grained data, e.g., "admin", "user", "unauthorized".  That
part of the patch did not make it in, however, because there was no
extant use case for it at the time.

Now that we have a use case, is this a feature that should be
resurrected?  Any opinions on what it should look like?
-- 
Kevin L. Mitchell <kevin.mitchell at rackspace.com>