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

[Alexander Bokovoy]

On Thu, 16 Apr 2015, Stanislav Láznička wrote:
>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.
And you are wrong here.
Olson database does have UTC as a timezone designator. I said previously
that this field should have just a value of Olson database and that's
fine. Simo was also talking about using an empty string to indicate 'use
timezone of the server' and I think with this we'd get a simple logic:

- if timezone value is empty (''), timezone of the target server is used, based
  on /etc/localtime value.
- if timezone value is not empty, it designates a timezone from Olson
  database.

No need to invent anything else here, in my opinion.


-- 
/ Alexander Bokovoy