[Freeipa-devel] Time-based account policies

[Nathaniel McCallum]

On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote:
> On Mon, 09 Mar 2015, Simo Sorce wrote:
> > On Mon, 2015-03-09 at 20:55 +0200, Alexander Bokovoy wrote:
> > > On Mon, 09 Mar 2015, Nathaniel McCallum wrote:
> > > > On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote:
> > > > > On Mon, 09 Mar 2015, Jakub Hrozek wrote:
> > > > > > On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek 
> > > > > > wrote:
> > > > > > > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> > > > > > > > On Mon, 09 Mar 2015, Martin Kosek wrote:
> > > > > > > ...
> > > > > > > > One of bigger issues we had was lack of versatile ical 
> > > > > > > > format
> > > > > > > > parser to handle calendar-like specification of events 
> > > > > > > > -- we
> > > > > > > > need to allow importing these ones instead of 
> > > > > > > > inventing our
> > > > > > > > own.
> > > > > > > 
> > > > > > > Good point. I wonder how rigorous we want to be. iCal is 
> > > > > > > a
> > > > > > > pretty powerful
> > > > > > > calendaring format. If we want to implement full support 
> > > > > > > for it, it would be
> > > > > > > lot of code both on server side for setting it and on 
> > > > > > > client
> > > > > > > side for evaluating it (CCing Jakub for reference).
> > > > > > > 
> > > > > > > AD itself has much simpler UI for setting the access 
> > > > > > > time, a
> > > > > > > table like that:
> > > > > > > http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
> > > > > > > 
> > > > > > > IIRC, they only store the bits of "can login/cannot 
> > > > > > > login" for the time slots.
> > > > > > > That's another alternative.
> > > > > > 
> > > > > > I don't think that's what Alexander meant, I don't think 
> > > > > > the
> > > > > > client library should come anywhere close to the iCal 
> > > > > > format. We might want to provide a script to convert an 
> > > > > > external format, but that's about it.
> > > > > > 
> > > > > > I thought we could simply reuse parts of the previous 
> > > > > > grammar, maybe simplified. But I agree with Nathaniel (as I
> > > > > > stated also in the private thread) that we should use UTC 
> > > > > > where possible.
> > > > > Yes and no. Let me go in details a bit.
> > > > > 
> > > > > We need iCal support to allow importing events created by 
> > > > > external tools. We don't need to use it as internal format.
> > > > > 
> > > > > However, there are quite a lot of details that can be lost 
> > > > > if only UTC would be in use for a date as you are ignoring a 
> > > > > timezone information completely. Timezone information needs 
> > > > > to be kept when importing and not always could be reliably 
> > > > > represented in UTC so that conversion from one timezone to 
> > > > > another could present quite a problem.
> > > > > 
> > > > > See   http://www.w3.org/TR/timezone/forsome of 
> > > > > recommendations.
> > > > 
> > > > I'm fine with a plan like this. I just want the admin to opt-
> > > > in to timezones. Localtime *by default* is fraught with 
> > > > pitfalls. If the admin needs local time policy, he should 
> > > > specify it exactly and should confirm the local time on 
> > > > affected systems.
> > > Yep. We need to make it easy -- probably by allowing to define 
> > > timezones as part of host object (like Martin proposed) and 
> > > overridden in HBAC service/service group. And all this have to 
> > > be very visual in the UI.
> > > 
> > > Another problem is how to deal with missing timezone information 
> > > at the place where HBAC rule with time rules would need to be 
> > > applied. We need to define the way we handle all these 
> > > (unavailable, non-parsable and other kinds of errors) timezone 
> > > info issues.
> > 
> > I would rather punt, than do some crappy thing ala Windows.

+1

> > Local Only or UTC only is always wrong.

+1. It was never my intent to imply this. :)

> > For some tasks 'local' is the only thing that makes sense (your 
> > morning alarm clock), for other things 'UTC' is the only thing 
> > that make sense (coordinated changes across multiple distributed 
> > data centers).
> > 
> > Implementing just one or the other is not useful.
> Correct. At this point I think we are more or less in agreement that 
> we need to store time rules in UTC plus timezone correction 
> information specific to the execution context (HBAC rule, host, 
> etc). Handling 'UTC' rule is equivalent to selecting specific 
> timezone (GMT+0, for example) so this is a case of more general (UTC 
> time, timezone definiton) pairs.
> 
> This timezone definition may have aliases forcing HBAC intepretation 
> to use local machine defaults if needed but the general scheme stays 
> the same.

Agreed.