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

Thu Apr 16 08:13:50 UTC 2015

Dne 16.4.2015 v 10:04 Stanislav Láznička napsal(a):
> On 04/16/2015 08:04 AM, Jan Cholasta wrote:
>> 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.
>>
> I was thinking "host", "utc" - these are not timezones. Maybe it would
> be more accurate to call it an anchor or a handle.

"UTC" is a timezone according to 
<http://en.wikipedia.org/wiki/List_of_tz_database_time_zones>.

The value usually is a valid timezone, I don't think we need to call it 
differently because of *one* value which is not.

>
> The timezone should probably be stored just once in the rule, you're
> right. In the design, I was aiming for not changing the schema, but it
> probably makes no sense to keep it as it is.
>>>
>>> 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.
>>
> On the other hand, names of days and months keep the rule more readable,
> which I think might be better when checking for mistakes in those rules.
>>>
>>> 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.)
>>
> Guilty there. It should really be multi-valued attribute. Although I
> think I would stick with just accessTime rather than accessTimeInclude.

Whatever suits you, but keep in mind that the exceptions need their own 
attribute.

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