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

Thu Apr 16 08:04:31 UTC 2015

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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20150416/7f8cbd97/attachment.htm>