[Freeipa-devel] URI in HBAC

[Jan Pazdziora]

On Tue, Apr 26, 2016 at 02:16:54PM +0200, Petr Spacek wrote:
> >>
> >> * 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).

The problem is that old clients will not ack for the new attributes
(they have no idea they should ask for them), so they will only see
parts of the HBAC rules.

So the question is -- what is the correct way to make sure that old
clients (that would not ask for the new attributes) are not served
any rules that have those new attributes set?

> > 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.

So you propose cartesian product of the schemes and URI attributes
to be used?

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