[Freeipa-devel] Time-based account policies

[Jan Cholasta]

Hi,

Dne 20.3.2015 v 13:30 Stanislav Láznička napsal(a):
> 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 ?).

Let me just do a braindump here:

I would think timezone, or rather location (timezone + holidays) should 
be stored with user objects (but not in group objects, as users can be 
members of multiple groups, which could cause conflicts). When a user 
goes on a bussiness trip etc., an administrator/manager would need to 
change their location accordingly to reflect that.

For hosts, timezone information is already available on the host 
(/etc/localtime). I'm not sure if there is a 1-1 mapping between 
timezone and holidays, but if there is not, we probably need to store 
location with host objects as well. If we do that, maybe we can make 
SSSD update local timezone on the host using the information stored with 
the host object to allow roaming (think user laptops).

It might be a good idea to store optional owner information with hosts, 
so that when the owner moves to a different location, the host is 
assumed to be at that location as well (again think user laptops).

Given the above, HBAC rules could contain (time, anchor), where anchor 
is "UTC", "user local time" or "host local time".

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

Honza

-- 
Jan Cholasta