[Freeipa-devel] URI in HBAC - code

[Lukáš Hellebrandt]

On 04/27/2016 03:34 PM, Lukáš Hellebrandt wrote:
> 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.
>>
> 
> 

Added a patch for backwards compatibility using different objectClass
for rules containing some of the new attributes:

SSSD: https://github.com/lhellebr/sssd/commits/url_in_hbac
FreeIPA: attached patch file (works together with the previously
submitted patch)

-- 
Lukas Hellebrandt
Associate Quality Engineer
lhellebr at redhat.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Use-new-objectClass-for-backwards-compatibility.patch
Type: text/x-patch
Size: 10618 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20160512/8506e99a/attachment.bin>