On Thu, Mar 24, 2016 at 02:30:06PM +0100, Petr Spacek wrote:
> I really do not like 'excludes'... Was an approach with longest prefix match
> considered as an option? I do not see it in the design page.
> E.g. imagine we have rules:
> / -> allow anyone
> /users -> allow all authenticated users
> /users/edit -> allow admins
> If the matching engine always selects rule with matchine prefix and evaluate
> only that rule, it would nicely express who is allowed to access what and did
> not require deny rules (or even rule merging).
The "Prefix" Evaluation item talks about it.
The perceived issue is, if for some reason you miss the longest
record when evaluating, you will use the previous shorter one and
allow more access than intended. So from certain POV it's similar to
DENY rules -- if you miss the DENY rule for some reason, you will go
with the allow rule.
If the excludes are kept up-to-date automatically for each URI
record, matching the next longer prefix, whatever record you find will
include in some attribute information about limits of its validity.
That might address the concern of security implication of exclude /
deny / longest record not found.
I don't like manual excludes either.
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code