[Freeipa-devel] URI in HBAC - code

[Lukáš Hellebrandt]

SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac
Apache module: https://github.com/lhellebr/mod_hbacauthz_pam
FreeIPA: http://pastebin.com/X6H9BTwk

On 04/26/2016 03:56 PM, Petr Spacek wrote:
> On 26.4.2016 15:16, Jan Pazdziora wrote:
>> 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?
> 
> Yes.
> 
> 
> Before we can discuss this further we need to see current LDAP schema and
> code. Lukas, please share the code with us.
> 


-- 
Lukas Hellebrandt
Associate Quality Engineer
lhellebr at redhat.com