[Freeipa-devel] [DESIGN][UPDATE] Time-Based HBAC Policies

[Standa Laznicka]

On 08/26/2016 12:27 PM, Jan Cholasta wrote:
> On 26.8.2016 12:21, Martin Basti wrote:
>> On 26.08.2016 12:13, Jan Cholasta wrote:
>>> On 26.8.2016 11:55, Martin Basti wrote:
>>>> On 26.08.2016 11:43, Jan Cholasta wrote:
>>>>> Hi,
>>>>>
>>>>> On 11.8.2016 12:34, Stanislav Laznicka wrote:
>>>>>> Hello,
>>>>>>
>>>>>> I updated the design of the Time-Based HBAC Policies according to 
>>>>>> the
>>>>>> discussion we led here earlier. Please check the design page
>>>>>> http://www.freeipa.org/page/V4/Time-Based_Account_Policies. The
>>>>>> biggest
>>>>>> changes are in the Implementation and Feature Management sections. I
>>>>>> also added a short How to Use section.
>>>>>
>>>>> 1) Please use the 'ipa' prefix for new attributes: memberTimeRule ->
>>>>> ipaMemberTimeRule
>>>>>
>>>>>
>>>>> 2) Source hosts are deprecated and thus should be removed from
>>>>> ipaHBACRuleV2.
>>>>>
>>>>>
>>>>> 3) Since time rules are defined by memberTimeRule, accessTime should
>>>>> be removed from ipaHBACRuleV2.
>>>>
>>>> ad 2) 3)
>>>>
>>>> Because backward compatibility, ipaHBACRuleV2 must contain all
>>>> attributes from ipaHBACRule as MAY
>>>
>>> Not true.
>>>
>>>>
>>>> With current approach, when timerule is added to HBAC, we just change
>>>> objectclass from 'ipahbacrule' to 'ipahbacrulev2' so we keep all
>>>> attributes that was defined in older HBAC. Removing any attrs from
>>>> ipaHBACRuleV2 can cause schema violation.
>>>
>>> Which is perfectly fine.
>>>
>>>>
>>>>
>>>> I'm not sure if want to handle this in code (removing deprecated
>>>> attributes from HBAC entry when timerule is added)
>>>
>>> We don't have to do anything. If any of the deprecated attributes are
>>> present when you change the object class (which they shouldn't
>>> anyway), you'll get schema violation, otherwise it will work just fine.
>>
>> I'm not sure if this is user friendly.
>
> You can obviously catch the schema violation and provided a meaningful 
> error instead.
>
I don't really have a strong opinion here. My point was to be able to 
hold all the attributes of the old type rule to be able to switch back 
without losing anything. Then the new objectClass would obviously be 
only used so that the older clients don't get the new HBAC rules that 
have the restrictions they don't understand.

On the other hand, we do not want the mess from the older rules there 
anyway if we want to use capabilities of the newer rule type so it might 
be fine. But if user wants to create a new rule from an old one they 
have to go through all the old attributes and manually remove their 
values which may be a bother for them. Also, I believe that there's code 
in SSSD that deals with some of these older attributes and this MIGHT 
cause schema violation even on SSSD side if we want to work with older 
HBAC rules in the same way as with the newer.
>>
>>>
>>>>
>>>> I realized that AccessTime is MUST for 'ipahbacrule', so when timerule
>>>> ('ipahbacrulev2') is removed and somebody deleted accesstime we 
>>>> have to
>>>> add it back.
>>>
>>> It is MAY. The only MUST attribute is accessRuleType, but that is
>>> deprecated as well and should be removed from ipaHBACRuleV2. We only
>>> support allow rules, so when timerule is removed, that's the value you
>>> set accessRuleType to.
>>>
>> Right, sorry.
>> Martin^2
>>
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>> 4) The CLI sections needs more work, especially for non-standard
>>>>> commands like timerule-test.
>>>>>
I definitely plan to look into the *test commands a bit more, I only 
drafted it quick yesterday.
>>>>>>
>>>>>> On the link below is a PROTOTYPE-patched FreeIPA that covers most
>>>>>> of the
>>>>>> CLI functionality (except for the creation of iCalendar strings from
>>>>>> options) for better illustration of the design.
>>>>>>
>>>>>> https://github.com/stlaz/freeipa/tree/timerules_2
>>>>>>
>>>>>> I will add FreeIPA people that recently had some say about this to
>>>>>> CC so
>>>>>> that we can get the discussion flowing.
>>>>>
>>>>> Honza
>>>>>
>>>>
>>>
>>
>