[Freeipa-devel] Time-Based Account Policies

[Alexander Bokovoy]

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).

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