[Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Stanislav Láznička]

Hi,

I have prepared a feature proposal for the wiki. I followed the Feature 
Proposal Template and the chapter "How to Test" is currently missing so 
it might rather be considered a draft. Please, see it, I hope it's alright.

The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules. 
However, handling access to a host in repeating time periods might be a 
desirable feature. The administrator of a certain environment should be 
able to set the time a host should be accessed in either the host local 
time, a certain time zone time or in UTC. Host-local-time policies would 
allow to adapt the time a host can be accessed to the host's movement 
along different time zones. A time bound to a certain time zone is more 
transparent than local time as it doesn't change with the host 
traveling. Sometimes, it may also be important to set time in UTC. This 
is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs to be 
accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain 
time zone. This access is repeated in a way, such as three times a week 
the same time except for once a year where there's regular maintenance.

Design
The time based account policies are an extension to the current (April 
2015) HBAC plugin. It assumes the time through the system is well set on 
all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three 
different views. These are: host local time, time at a certain time 
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely 
to move across different time zones and for some reason it's important 
that the time they can be accessed reflects their current position. This 
helps creating only a single HBAC rule instead of multiple when only 
time zone or UTC rules would apply. The time of a host is counted using 
the /etc/timezone information of the certain host. Testing of such rule 
requires the tester to specify a certain time zone the rule would be 
tested against.
It's important to note that this type of policy may bring some 
unexpected behavior as hosts move across the globe, or even in a single 
hostgroup, when there're hosts from multiple timezones, and 
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain time 
zone. This might be interesting when the time settings should reflect a 
certain time zone, eg. the host or the users connecting to it are to be 
found in that certain time zone. The time zone offset to count the time 
of access is taken from the Olson database. Therefore, even daylight 
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the same for 
the whole globe throughout the year. That's why UTC should also be 
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that applies 
such a policy. This extension is designed so that the LDAP schema does 
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC 
rule object. The policy is a string in a form of tuple: (anchor, time). 
In this tuple, the anchor is one of "host", "utc" or Olson database time 
zone name, such as "Europe/Prague". The meaning of the anchor follows 
the time scenarios from this design. The time part of the policy tuple 
is the time range of the policy.

The language of the time half of the time policy tuple is inspired by 
the time part of Bind Rules of 389 Directory Server. Aside from the Bind 
Rules keywords timeofday and dayofweek, it adds keywords dayofmonth, 
weekofmonth, monthofyear and year. There are three operators: assignment 
("="), range ("-") and union(","). Assignment operator is used after 
each of the keywords above to specify the value of the certain keyword. 
Range operator may be used for setting ranges of hours, days, months 
etc. The final range includes both boundaries of the range set. A union 
operator is used when the keyword should contain a union of values 
rather than a range. Also, it can be used to make a union of ranges.

Possible values of each keyword:
timeofday       0000-2359
dayofweek       Mon, Tue, Wed, Thu, Fri, Sat, Sun
dayofmonth      1-31
weekofmonth     1-5
monthofyear     Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
year            a year

Example:
(host, timeofday="0800-1200, 1230-1600" dayofweek="Mon-Thu, Sat")

Similarly to Bind Rules, it is possible to write an time policy as a 
longer expression using the "and" and "or" logical operators. In this 
case, each of separate block of the policy should appear in parentheses. 
It is also possible to add time exceptions for the policy. That's 
performed using the except() block that should appear only once in the 
time policy and should enclose all possible time exceptions for the policy.

Example:

((timeofday="0800-1600" dayofweek="Mon-Wed") or (timeofday="1600-2400" 
dayofweek="Wed-Thu")) except (dayofmonth="4" monthofyear="July")

Feature Management
UI
The UI of HBAC rules should now include new bar for adding time 
policies, similar to the user, host and service bars. Rather than "Any 
time" and time specified, there should be options "Any time", "UTC", 
"Host-local time" and "Specified timezone" with a timezone specification 
tool (similar to the one in GNOME/Date & Time Settings). User should be 
able to add more time policies for an HBAC rule to have similar behavior 
to the one with adding users, services and hosts. Between these multiple 
policies would be logical OR relation.

A view of adding a policy should contain a text array for the time 
policy string. At the top of this array, there should be a hint 
explaining the policy syntax. The format of the time policy should be 
checked upon time policy submit button press.

CLI
Time policies at CLI would be set in a similar manner as in the UI. 
Administrator needs to specify how the time should be understood 
("host", "utc", Olson's timezone name) and the time of access according 
to the syntax described above:

ipa hbac-set-accesstime-anchor anchor
ipa hbac-add-accesstime timeipa hbac-remove-accesstime num

When using CLI for access time setting, the default anchor should 
probably be UTC, setting anchor with each new time policy might get 
confusing as the anchor should change with all the policies for that 
certain HBAC rule. When removing a time policy, it makes sense to rather 
remove it by the list position of the policy among other policies.