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

[Jan Cholasta]

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):
> 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.

It should be called "timezone", not "anchor". Anchor was something 
different (and I really regret calling it that, seeing how it got stuck).

Is there any real benefit in storing time zone with each access time? I 
think it should be good enough to have one time zone per HBAC rule, 
which would also reduce complexity of the whole thing.

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

IMO dayofweek and monthofyear should use number as well. Numbers are 
easier to process.

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

I thought we agreed on using multiple attribute values rather than one 
long attribute value:

     accessTimeInclude: timeofday="0800-1600" dayofweek="Mon-Wed"
     accessTimeInclude: timeofday="1600-2400"
 > dayofweek="Wed-Thu"
     accessTimeExclude: dayofmonth="4" monthofyear="July"

Yes, we would loose "and" operator, but do we really need it? (IMHO we 
don't.)

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

Again, s/anchor/timezone/.

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

Honza

-- 
Jan Cholasta