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

[Alexander Bokovoy]

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.
>>
>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.
-- 
/ Alexander Bokovoy