[Freeipa-devel] Time-based account policies

[Nathaniel McCallum]

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/for some 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.

Nathaniel