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

[Standa Láznička]

On 4/16/2015 10:26 AM, Alexander Bokovoy wrote:
> 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.
>
>
Oh, I see. No problem calling it a timezone, then, as such description 
is accurate.