[Freeipa-devel] Time-Based Account Policies

[Stanislav Laznicka]

On 07/10/2015 01:10 PM, Petr Vobornik wrote:
> On 07/10/2015 12:43 PM, Alexander Bokovoy wrote:
>> On Fri, 10 Jul 2015, Stanislav Laznicka wrote:
>>> Hi,
>>>
>>> Long time no post from me, time to make it up to you.
>> Welcome back!
>>
>>> I have been working on the the implementation of the design of time
>>> policies for HBAC rules on FreeIPA and SSSD sides. Attached is the
>>> current state of the FreeIPA solution. My comments and notes to the
>>> solution follow.
>>>
>>> The FreeIPA side backend base for time policies in HBAC seems working
>>> to me but still needs formal testing. Also, there is no conversion
>>> from the iCal format as previously requested and I personally would
>>> postpone this feature until the time policies functionality is rock
>>> solid.
>>>
>>> There were some uncertainties in the design as well. I ran into 2 of
>>> these but more may come.
>>>
>>> The first thing is how to deal with weeks in a month. There are two
>>> possibilities. A week in month (as specified by the weekofmonth
>>> keyword in the time policies) may be understood as a period of time
>>> between two Sundays, so when a month starts on, say, Friday the 1st,
>>> weekofmonth=1 would specify days Friday, Saturday, Sunday and anything
>>> from that Sunday on would be a weekofmonth=2 and on. However, I think
>>> a week in a month may also be considered a period of time that equals
>>> 7 days of a month. In the previous example, a weekofmonth=1 would
>>> therefore also apply to the following days up until Friday the 8th,
>>> excluding this last day. Although I implemented the first case in the
>>> SSSD, I actually started thinking the second case scenario might be
>>> the right or "better" one.
>> One thing you need to realize that there is no universal 'week starts on
>> Sunday'.
>> There are different ways of starting a week, some countries do it on
>> Sunday, some -- on Saturday, some -- on Monday. This means you need to
>> make possible to pull in a locale definition if you really want this
>> functionality and then it also becomes quite fuzzy as there are legal
>> definitions of what a week is (as well as a month and a work day).
>>
>
> Yes, it could be more complicated, e.g. see Week Of Month in Java:
> """
> week-of-month: The calculation ensures that weeks never overlap a 
> month boundary. The month is divided into periods where each period 
> starts on the defined first day-of-week. The earliest period is 
> referred to as week 0 if it has less than the minimal number of days 
> and week 1 if it has at least the minimal number of days.
>
>
> public int getMinimalDaysInFirstWeek():
>
> Gets the minimal number of days in the first week.
>
> The number of days considered to define the first week of a month or 
> year varies by culture. For example, the ISO-8601 requires 4 days 
> (more than half a week) to be present before counting the first week.
> """
> https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html 
>
>
That is a pretty good example of what a week is, thanks.

I don't think I would want the functionality of having weeks begin with 
different weekdays according to locale. I would rather stick to the ISO 
8601 as described in the link Petr sent. I was rather wondering whether 
weekofmonth should mean the x-th appearance of a day in a month or an 
appearance of this day in x-th week of the month. However, the 
definition above is quite strong and I think I could live with a week 
starting only on Monday and having 0-th weeks in month.
>>> The other thing is which years should be allowed to be the input of
>>> the "year" keyword. Currently, I set the range for these values to
>>> 1970-2038 according to the Unix timestamp. I'm not sure if anyone
>>> would want to set it less than 1970, setting it for a higher value
>>> than 2038 might probably make sense in some very special cases,
>>> although I really can't think of a one.
>> You certainly can set it more than 2038 (time doesn't stop there). What
>> you are limited with is Kerberos 32-bit time stamp, not HBAC policy time
>> definition. I would say we better set to 64-bit ourselves and handle
>> irregularities in SSSD.
>>
>
> Yes, we should talk.
>
> Some comments from looking on patch 0004:
> 1. list of time zones should be moved to a module property so that it 
> can be reused else where if needed. Other possibility is to get this 
> list from backend, e.g. on Web UI load or something.
>
> 2. please don't do any changes to patternfly.js. It's updated only 
> when bundled PatternFly is updated. Long term goal is to get it out of 
> FreeIPA git.
>
> All IPA css changes should be done in install/ui/less/*less files - as 
> you did in widgets.less. From these .less files an 
> install/ui/css/ipa.css file is created. Note that there is also 
> install/ui/ipa.css which contains most of the ipa specific styles. 
> It's planned to move these styles to .less files as well.
I put those 2 last commits together, the only difference there was that 
once the styles were set correctly (0005) and incorrectly in the 
previous patch (0004). Attaching the last commit, also hopefully with 
correct formatting as pointed out by Martin Basti. I should add the list 
of time zones to a module property in later commits.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Created-basic-UI-for-setting-time-policies-at-HBAC-r.patch
Type: text/x-patch
Size: 17675 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20150710/2767b47c/attachment.bin>