[Freeipa-devel] URI in HBAC - design page

[Lukáš Hellebrandt]

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
lhellebr at redhat.com