[Freeipa-devel] [Update]Time-Based Account Policies

[Simo Sorce]

On 16/11/15 13:20, Alexander Bokovoy wrote:
> On Mon, 16 Nov 2015, Simo Sorce wrote:
>> On 16/11/15 06:02, Ludwig Krispenz wrote:
>>>
>>> On 11/16/2015 10:32 AM, Martin Kosek wrote:
>>>> On 11/13/2015 04:40 PM, Simo Sorce wrote:
>>>>> On 13/11/15 10:17, Martin Basti wrote:
>>>> ...
>>>>>>> And in general I am opposed to have a separate object on performance
>>>>>>> grounds (for clients) and also on the fact that is becomes tricky to
>>>>>>> keep objects in sync.
>>>>>> What exactly is the performance issue there? To download extra entry
>>>>>> from LDAP?
>>>>>
>>>>> Yes because now you have to download rules, parse them, find out what
>>>>> needs tro
>>>>> be downloaded and pull it, or wore just download all time rules
>>>>
>>>> Just for the record, you should be able to pull that in one LDAP
>>>> search, when you cast dereference on the HBAC time linking attribute
>>>> and pull the settings from time object also.
>>> but then you will have the corresponding internal searches, and the use
>>> of the deref control is not always efficient.
>>>
>>> If you want to define general rules like "brno" or "rest of the world"
>>> to reuse rules, why not use CoS and define virtual attributes in the
>>> entry, which would be populated by CoS. The client would have to read
>>> only one entry, the CoS allows flexibility to assign rules to entries
>>
>> The nice thing about keeping it in the HBAC entry is indeed that we
>> *ca* use CoS ... or not. We can decided that w/o breaking the schema.
>>
>> I think we will mostly *not* want to use CoS, but it remains an option.
>>
>> CoS is partially undesirable because it makes any change to the time
>> policy an immediate change to all HBAC rules that reference them.
>> While if times rules are templates, then a change to a time rule can
>> be tested before applying it to all rules that reference it and you
>> also have the option to have some HBAC rules break off and go on their
>> own.
>>
>> It makes for a potentially more flexible and error forgiving system in
>> this case.
> I don't see any contradiction here. You can create CoS configuration
> based on the instantiated template entry. That's why I wrote in the
> other answer we need to extend our current cosentry_* support a bit.

I wasn't implying any contradiction, I hadn't even read your message yet 
when I replied to Ludwig, sorry :-)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York