[Freeipa-devel] Time-based account policies

[Stanislav Láznička]

Hi!

I went through the last week's thread on Time-Based Policies, discussed 
some parts I wasn't very sure about with Martin, and would like to make 
a summary of it, followed by some further questions on the topic. The 
mail is a bit longer than I thought it would be. Sorry about that. It 
seems I am very bad at fast and brief responses.

So to summarize - the best way to go seems to be to implement both UTC 
and client-side local time support. A very nice idea is to store it in 
the format (time, timezone). Now if I understand this right, the 
timezone here would be the Olson database timezone stored with the 
host/hostgroup, possibly overridden by service/servicegroup timezone. It 
would help the administrator decide the correct UTC time by adjusting 
the time displayed in UI/CLI. The administrator should also be able to 
set this timezone in the UI/CLI settings of the HBAC rule (or maybe they 
just set it instead of storing timezone info with host/hostgroup etc. 
objects?).

As for the local time - timezone in the tuple (time, timezone) would 
only say "Local Time", which can't be found in Olson's and it means the 
time record from the tuple should be compared to the client's time 
settings (/etc/localtime ?).

What would then be left to decide is whether to use the iCalendar time 
format as internal, or use some other own created format. Such a format 
should not only be suitable for reoccurring events, but should also be 
able to handle exceptions in those events, such as holidays. It should 
also be easy to import iCalendar events to this format to support events 
from other sources.

The iCalendar format is rather heavy and if we wanted to use it as a 
whole, it may be necessary to include third party libraries in the SSSD 
project along with their possible vulnerabilities. There is a 
possibility of using only part of the iCalendar format that handles 
reoccurring events and exceptions. Example from Alexander to be found 
here: 
https://github.com/libical/libical/blob/master/src/test/icalrecur_test.c. That 
may or may not work perfectly well, given the libical library is a 
complex thing and we'd be taking just a part of it.

The other time format option is to simplify/edit the language that was 
used in the past (described with regular expressions here: 
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=1ce240367a2144500187ccd3c0d32c975d8d346a). 
There was probably a reason to step out of the language (the possibility 
of parsing those iCalendar events, I guess) and it may or may not be 
possible to fix the language so that the problems with it are dealt with.

I was also inspired by the language of the time part of Bind Rules from 
389 Directory Server and created a possible language that might be 
usable. I don't have yet the regular expression describing the language 
in a human-friendly form but I got a finite automaton picture that 
describes it (see https://www.debuggex.com/i/_Pg9KOp2TgXuus8K.png). 
Basically, you have the parentheses form of rules from Bind Rules, 
separated with either "and/or" or "except" keyword. "except" should only 
appear once. You would set the time ranges with the "-" operator, e.g. 
timeofday=0800-1545 (this operator is not shown in the picture). The 
parenthesis could also be nested but that can't of course be described 
by a finite automaton. The "except" keyword should still appear only 
once, though. If any time-describing part is missing, it means that 
access is allowed (e.g. (timeofday=0800-1600 dayofweek=Mon-Fri) allows 
access from 8:00 to 16:00 Monday through Friday any week in the month, 
any month in the year). This language should be able to do everything 
the old language did, supports reoccurring events nicely and also allows 
exceptions, so importing iCalendar events might be possible. However, 
its downfall is that it's not very space-efficient and absolute time 
ranges may not be so easily be described (e.g. time from 18:00 20.3.2015 
to 23:00 24.12.2015 would be quite a string).

MY QUESTIONS: Do we store the timezone information with the 
host/hostgroup, service/servicegroup object or do we just have the admin 
pick the timezone themselves? Which time format would be best for both 
FreeIPA and SSSD?

Thank you very much for you insights!
Standa