On Mon, Feb 29, 2016 at 11:50:06AM +0100, Lukáš Hellebrandt wrote:
On 02/28/2016 11:42 AM, Jakub Hrozek wrote:
> On Fri, Feb 26, 2016 at 02:03:37PM +0100, Lukáš Hellebrandt wrote:
>>> First question I have is that the URLs only match on complete string
>>> match. From past conversations I thought we wanted to add a more
>>> granular evaluation..?
>> I am planning to interpret URI as a prefix. However, there might be
>> problem getting enough granularity because FreeIPA has dropped DENY
>> rules: it will be hard to get some behaviors, e.g. "Allow access to
>> hostname/* but not to hostname/admin/*". I do not know yet how to solve
> Wouldn't it help if all rules that match URI-wise need to allow the
> person requesting the resource?
I am not sure if I understand.
The problem is, I do not know how to make a rule to allow "everything
Just don't do it, the current HBAC rules don't support that either :)
E.g., allow every URI that does NOT start with
$(hostname)/admin/ . It would be possible if there was finite number of
prefixes other than $(hostname)/admin , but it might not be the case.
In this example "hostname" would be an HBAC service. Then there might be
additional URI rule "/myapp/*" that would be permitted for the
group and an URI rule "myapp/admin*" that would be permitted for the
'appadmins' groups. An attempt to access anything under "myapp/admin"
would match both URIs, but unless the user requesting access was a
member of appusers, one of the two rules wouldn't match and access would