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

[Martin Basti]

On 18.05.2016 16:13, Alexander Bokovoy wrote:
> On Wed, 18 May 2016, Stanislav Laznicka wrote:
>> On 05/18/2016 02:19 PM, Alexander Bokovoy wrote:
>>> On Wed, 18 May 2016, Stanislav Laznicka wrote:
>>>>>> when removal succeeds but addition fails for some reason? The 
>>>>>> operation is not atomic anymore.
>>>>>>
>>>>>
>>>> We offline-discussed this with Honza. There should be a new command 
>>>> `ipa hbacrule-replace-accesstime rule_name --orig-time=icalstr1 
>>>> --new-time=icalstr2`. As it would be derived from LDAPQuery, the 
>>>> atomicity is kept. This may not be very nice for CLI but should 
>>>> work well for WebUI. Both icalstr1 and icalstr2 need to be encoded 
>>>> as newlines that appear so often in iCalendar strings would only 
>>>> make a mess here.
>>>>
>>>> Example of use:
>>>>
>>>> ipa hbacrule-replace-accesstime rule_name 
>>>> --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 
>>>> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" 
>>>> --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j 
>>>> 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r\\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:20101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'"
>>>>
>>>>
>>>> to add Tuesdays to the timespan defined by the rule.
>>> I would really like to see a file input support here. It would be
>>> simpler to operate in CLI as you would anyway create vCal files -- no
>>> sane person is going to deal with these strings directly on the command
>>> line.
>>>
For sure we should support import of iCals, but we should have simple 
interface for creating simple iCal, such as from 13:00, to 15:00, on Mo, 
Tu and Fri. For extra special rules the one may use iCal generator 
somewhere.

Martin^2

>> That is correct and some basic file support is already in the patches 
>> I sent earlier, though replacing rules is not a part of it. However, 
>> it does not solve the problem as you would still need access to the 
>> files to work with the attributes and then change the files accordingly.
>>
>> However, we've had yet another brainstorm with Petr^2, Martin^2 and 
>> Honza. We really don't want the above so we came up with some ideas 
>> that I'm listing below. Note that we also do not want more than one 
>> VEVENT component in any of the time rules. So, the ideas:
>>    1) Have the time rules as separate objects. This approach got most 
>> support here. Adding Simo and Jakub to CC should they have any input 
>> against this.
>>    2) Have the time rules stored as strings in the multi-valued 
>> accesstime attribute at each rule. These would be referenced by their 
>> UID property of the VEVENT component of the iCalendar string (instead 
>> of that pure hell above). As each of the strings can only contain one 
>> VEVENT which has to define a UID, the only problem would be to keep 
>> the uniqueness of UIDs consistent.
>>
>> From my point of view, 1) seems rather better but your experience 
>> might be different. Don't hesitate to share your opinions, please.
> I'm for time rules as separate objects too. Multi-valued accesstime
> attributes would not work well because you cannot really address
> attributes by UID.