Dne 16.4.2015 v 10:04 Stanislav Láznička napsal(a):
On 04/16/2015 08:04 AM, Jan Cholasta wrote:

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

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

The text:

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.

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.

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

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.

(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


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

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

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.


Jan Cholasta

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to