[Freeipa-devel] URI in HBAC - design page

[Jan Pazdziora]

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.

-- 
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat