[Freeipa-devel] Time-Based Account Policies

[Stanislav Laznicka]

On 08/03/2015 11:45 AM, Alexander Bokovoy wrote:
> On Mon, 03 Aug 2015, Stanislav Laznicka wrote:
>> Hi,
>>
>> I have made some changes to the structure of the HBAC time rules 
>> extension, namely the code that validates the time rules' strings was 
>> moved from the ipalib/parameters to the hbacrule module itself, and a 
>> more "fresh" approach was used in code for methods of adding/removing 
>> time policies to HBAC rules.
> Thanks for the advances. :)
>
>> A slight change was made to understanding a week in a month. The 
>> change follows the Java implementation of a week in a month as 
>> suggested by Petr V., given a week starts on Monday (=1; iso 8601). 
>> More on that on the previously mentioned link
>>
>> https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html 
>>
>>
>> What this change means is that a first week in a month is a week that 
>> contains at least 4 days. If it has less days, it's 0-th week 
>> (probably better than having it belong to the previous month as some 
>> sources also suggest - iso 8601 does not have a definition for a week 
>> in month but it has a definition for a week in a year).
> Sounds fine.
>
>> I had Jan C. check the current implementation of the FreeIPA side for 
>> the time-based policies and it seems to work as is. He created 
>> official number identifiers for the 2 new LDAP attributeTypes, too. \o/
>>
>> I was also going through some old mockups for the WebUI Petr V. sent 
>> me earlier last month. It brought some questions worth sharing here.
>>
>> 1. Do we need time rules based on the day and week of the year? 
>> Currently, there is no such option as dayofyear or weekofyear in the 
>> rules language, although adding it should not be that much of a 
>> problem. I did not include them as it seemed more convenient to set 
>> the data as combinations of dayofmonth and monthofyear values.
> In business circles it is increasingly common to refer to events by
> their week numbers, especially in logistics and factory delivery.
>
> See http://www.cl.cam.ac.uk/~mgk25/iso-time.html for some details at the
> end of 'Date' section.
>
It should go right in, then.
>
>> 2. Should we add dayofyear and weekofyear, a possible need for 
>> "intervals" might be required. An "interval" is a behavior from the 
>> iCalendar format. It basically functions as range() in Python, 
>> although with possible 'infinite' end. Example: should you have a 
>> recurrence rule on daily basis with interval=2, a rule would apply on 
>> every other day. This is kind of a question of keeping it easy and 
>> light or heading a way of robust implementation during which dragons 
>> may appear, although with a tiny tiny possibility of a golden 
>> treasure in the end.
> Yes, I think intervals are required.
>
Alright. I gave it a little thought considering the current state of the 
language for time rules and considering where I should go with these 
intervals. The thing about the 'interval' in iCalendar is that to use it 
it is necessary to also add at least the 'frequency' and 'startdate' 
elements to the language. With that, adding 'enddate' and 'count' 
optional elements should not be that bad. What I am hoping for is that 
the same functionality as in iCalendar can be achieved here and so far I 
do not see why not.
>> 3. The mockups for HBAC time policies show quite a wizard-like UI. 
>> While I might be very wrong here, I was thinking of rather a simple 
>> UI where user would be able to set the values for each of the rule 
>> keywords (timeofday, dayofweek, ...) directly in some text input 
>> fields with possible help of JavaScript, that would add text 
>> description to the user input (e.g. "Monday to Friday" with user 
>> input "1-5" at the dayofweek input field).
> With JavaScript support your wizard-like approach would still work
> within the same page -- instead of moving 'next', you would need to
> modify a number of available input fields based on selected items.
> That's possible and I don't see much of trouble with it.
>
>> 4. Do we want some special settings for "absolute" time policies 
>> (policies that start and end at certain time in year)? The issue now 
>> would be that some of such rules would have to be broken down in more 
>> than one time rule (e.g. rule starting at a certain time of a day in 
>> a month in one year and ending at a certain time, day and month of a 
>> different year might get broken down to up to 6 rules if I count 
>> right). This could actually be solved by a UI wizard-like setting 
>> where the user gets to pick the dates and times of the rule, a 
>> conversion method would need to be created and such a thing would 
>> then work for the CLI, too. Still, usually more than one time rule 
>> would be created for such cases.
> Same here.
>
I might not have expressed myself clearly there, for which I am sorry. I 
was rather thinking that instead of different 'screens' for different 
time scenarios, like "Yearly", "Daily", etc., user should be able to set 
all the values in one UI pop-up screen directly as number values in text 
fields (with the exception of "absolute" time policies, perhaps). While 
the user experience may suffer a bit, to me it seems more clear, 
readable and flexible than to have some elements such as checkboxes and 
selects take care of that (although the values around the "interval" 
from iCalendar discussed here earlier would probably need just that). 
Hopefully, I made myself clearer here :)