[Freeipa-devel] URI in HBAC

[Petr Spacek]

On 26.4.2016 12:57, Jan Cholasta wrote:
> Hi,
> 
> On 25.4.2016 14:48, Lukáš Hellebrandt wrote:
>> http://www.freeipa.org/page/V4/URI-based_HBAC
>>
>> I have made some important changes to the design document of this
>> proposed feature. The difference is mainly changing regular expression
>> interpretation of URI to longest-prefix matching.
>>
>> This change was done mainly because of upstream's reactions. I value any
>> further comments and particularly discussion about the two topics
>> mentioned at the end of the design page:
>>
>> * For backwards compatibility, lack of URI in request means any URI is
>> matched (as described in the design document). Is it a good idea? Any
>> other solution?
> 
> For other attributes in HBAC rules, the lack of a value means nothing is
> matched. To match anything, you have to set "${attribute}category" to "all". I
> would prefer if URI matching was consistent with this, if it's possible.

My understanding is that requests lacking URI parameter should not match any
HBAC rules with non-empty URI. This will be backwards compatible because old
clients will simply ignore new rules which cannot be evaluated properly anyway
(for lack of information in client's request).


>> * How about multiple URI's in one HBAC rule? Is it a good idea? How to
>> interpret combinations of host+scheme+port (one field) and URI paths
>> (another field) in that case?
> 
> I think it is not only good idea, but actually necessary. I guess you would
> have to consider an URI matched if it's host+scheme+port matches any of the
> host+scheme+port patterns and at the same time it's path matches any of the
> path patterns.
> 
> BTW what is the reason to split URIs into separate fields? If it's just case
> sensitivity, I would like to point out that you can switch case sensitivity on
> and off in the middle of a Perl regex using "(?i)" and "(?-i)".

Personally I would rather see host+scheme+port split into separate attributes.
That would allow reporting like 'give me all rules for FTP' etc. without
substring magic.

And yes, I agree with Honza that multiple values should be evaluated as
logical OR.

E.g.

schemes: {http, https, ftp, ftps}
URI: /home/pspacek
host: any
allow: pspacek
should grant user pspacek access to directory /home/pspacek on any host as
long as the scheme is http/https/ftp/ftps.

-- 
Petr^2 Spacek