On 03/24/2016 10:24 AM, Jan Pazdziora wrote: > On Wed, Mar 23, 2016 at 04:41:49PM +0100, Lukáš Hellebrandt wrote: >> I created a design page for the feature: >> >> http://www.freeipa.org/page/URI-based-HBAC-design > > The way most web applications (that I see as the first use for this > feature) are structured, they have more openly accessible areas at > "top" URLs like > > /application/ > > which might have unrestricted access, with authenticated or otherwise > narrowed access underneath, like > > /application/users/ > > with yet more restricted areas in sub-URLs, for example > > /application/users/admin/ > > Since obviously allow rule for /application/users/ would match access > to /application/users/admin/ as well and we don't want that, there > needs to be a way to "override" the /application/users/ rule with > a more specific one. > > You present two solutions to the problem -- deny rules, and regular > expressions. > > Having to use > > ^/application/users/(?!admin/).* > > rule to make sure it does not match /application/users/admin/ means > that when you add > > /application/users/helpdesk/ > > you will not only have to edit that rule, but also amend the > > ^/application/users/(?!admin/).* > > rule and add helpdesk there. That will be extremely volatile and > error-prone if you have dozens of sub-locations that require > separate, more restrictive access. Users cannot be expected to keep > these separate rules in sync. > > My preferred solution would be to treat the URL as left prefix, and > maintain for each URL/rule list of/links to sub-URLs/sub-rules for > which the URL/rule no longer applies. > > So when you have rule for > > /application/users/ > > and add rule for > > /application/users/admin/ > > the first one gets automatically amended to be > > /application/users/ [ admin/ ] > > And when you add > > /application/ > > it will automatically get > > /application/ [ users/ ] > > because there is already a rule that limits the scope. > > The benefit of this approach is that if you need to evaluate access > to say > > /application/data/ > > and you already have rule for > > /application/ [ users/ ] > > cached either in SSSD or in the application (Apache module), you know > you don't have to refetch additional rules because if they existed, > their existence would be noted in the sub-URL "exclusion" list. > > You will achieve similar functionality to what you propose with the > regular expression approach, except the computers will do the work > of keeping things in sync, not users. >
This solution would, effectively, mean DENY rules. Without them, adding "/application/users/admin/" wouldn't change anything as the first rule would allow "/application/users/.*" and the added rule would explicitly allow "/application/users/admin/.*", changing nothing. Furthermore, in some cases you might, for example, allow access to any user except users starting with "admin_", which is a problem if there is unknown or infinite or large number of those users. Regular expressions seem to be more powerful. -- Lukas Hellebrandt Associate Quality Engineer lhell...@redhat.com -- 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
