On 24.3.2016 14:08, Martin Kosek wrote: > On 03/24/2016 01:24 PM, Jan Pazdziora wrote: >> On Thu, Mar 24, 2016 at 12:38:37PM +0100, Martin Kosek wrote: >>> On 03/24/2016 10:24 AM, Jan Pazdziora wrote: >>>> On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote: >>> ... >>>> You present two solutions to the problem -- deny rules, and regular >>>> expressions. >>> >>> For the record, HBAC deny rules is something we will want to avoid. Deny >>> HBAC >> >> Certainly. And for the current HBAC's model of user (groups), host >> (groups), service (groups), you can tell the admin to structure their >> environment and groups in such a way that they are not needed. > > Right. > >> But the question is, if you want for the admin to be able to control >> access to a website where longer URLs often need to be more restricted >> than the shorter ones, what mechanism do you propose? It is not >> possible to positively (for allow purposes) list only exhaustive list >> of URL prefixes that should have the broader access allowed -- new >> versions of the web application can introduce additional URLs into the >> namespace, and the URLs are not identities like users or hosts that >> FreeIPA would be aware of that that you could easily manage by putting >> them to groups. > > I agree it is complicated. While Deny HBAC rules is something we do not want, > allowing exclusive rules for an HBAC URI rule may be acceptable. This would be > the same approach we chose with Exclusive Time rules in Time-Based HBAC: > > http://www.freeipa.org/page/V4/Time-Based_Account_Policies#Time_Policies_Storage > > For the URI identifiers, we should also try to reinvent the wheel here. Can > adopt an approach used in some of the most common frameworks for URL matching? > Take Django for example: > > https://docs.djangoproject.com/en/1.9/topics/http/urls/ > > Using the pattern approach you mentioned elsewhere could work, I am just > worried how much user friendly it would be for non-developers. But we can also > make use these patterns as the raw storage format and build some nice UI/CLI > on > top of it. > >> The natural way to think about access to web URLs is to say "I only >> want admins to access /application/users/admin/". Which of course >> means "I want to deny everyone who has otherwise access to other URLs, >> except for admins". > > Can we do the same as with current default "allow all" rule? I.a. allow "/" > for > all sites by default and let admin to remove that for sites with access > controlled and restricted by FreeIPA HBAC. This would mean admin would > typically need to define some general rule the site accessible by all with the > exceptions defined in "exclude" access rules and then build the rules specific > to these excluded parts of the application URL tree.
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). -- Petr^2 Spacek -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
