[Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/26/2015 02:40 PM, Standa Láznička wrote:
> On 3/26/2015 1:24 PM, Martin Kosek wrote:
>> On 03/26/2015 01:08 PM, Standa Láznička wrote:
>>> On 3/26/2015 11:13 AM, Jan Cholasta wrote:
>>>> Dne 25.3.2015 v 18:25 Stanislav Láznička napsal(a):
>>>>> On 03/25/2015 12:34 PM, Alexander Bokovoy wrote:
>>>>>> When using hbactest command you just need to supply implied time zone
>>>>>> as an option to the command itself. After all, you are simulating rule
>>>>>> execution so it does not matter where the value comes from.
>>>>> Oh, good, I haven't thought of that. That certainly eases things up.
>>>>>
>>>>> Let me make a summary then, a short one this time, of what's been
>>>>> discussed .
>>>>>
>>>>> It seems the best way to store time policies is indeed the format (time,
>>>>> anchor) where anchor is either Olson database timezone or "Local Time"
>>>>> for host local time. We are omitting users' local time because, after
>>>>> all, we are talking HBAC Rules here (great point by Simo). If the admins
>>>>> really needed that, there's a workaround Jan mentioned that should work
>>>>> just fine.
>>>> What I originally meant as anchor was a value specifying the time offset
>>>> (e.g. "utc" - access time uses UTC, "rule" - access time uses time zone
>>>> specified in the HBAC rule, "host" - access time uses host's time zone),
>>>> rather than the time zone itself or "Local Time".
>>>>
>>> You're right, that's probably more descriptive than just "Local Time". Still, I
>>> think that instead of "rule" a timezone might just as well appear on the anchor
>>> part. I think "UTC" is also part of Olson's so it should be at the same spot as
>>> the timezone.
>> I am not little confused about all the places where we want to add the time
>> zone. I thought that it was originally meant for hosts objects, so that we can
>> HBAC rule is created, UI/CLI can already suggest the right time zone for the
>> HBAC rule. But it should have been only informative value serving mostly UX,
>> not something that SSSD would decide on.
>>
>> HBAC rule itself is always the authoritative source. We should also avoid
>> having time zone in 2 places in the HBAC rule itself - if this is what you are
>> steering at. I thought the authoritative time zone would be only in the HBAC
>> time definition only, i.e. only in the anchor specifically.
> I think the timezone still may be with the host object but only as the UI
> helper as you suggest. Although I would maybe rather not see it with the object
> at all and have the admin just set the right timezone for the HBAC rule
> themselves. After all, if there's a collision of host helper timezones, I think
> admin would have to do that anyway.

Right. But UI could then offer:

Warning, time zone is ambiguous. Please select the right time zone:
HostA time zone: Europe/Prague  [ ]
HostB time zone: Europe/London  [ ]

> I agree that there should only be one timezone record for each HBAC and I
> wouldn't suggest differently. There was a confusion when Jan suggested to use
> "rule" as anchor in the (time, anchor) tuple to get the rule's timezone which,
> he suggested, should be stored elsewhere but in the tuple. I think there's no
> harm having the timezone/"host" keyword stored with this tuple and therefore
> nowhere else.
>> Can we show specific examples of these tuples, to make sure we are in
>> agreement? My take was:
>>
>> (Mon-Fri 08:00-17:00, UTC+1)
>> (Mon-Fri 08:00-17:00, local)
>>
>> UTC+1 may not be ideal as it would not work for daylight saving, a better way
>> would indeed be the Olson time zone ID, i.e:
>>
>> (Mon-Fri 08:00-17:00, Europe/Prague)
>> (Mon-Fri 08:00-17:00, local)
> Definitely the second format ((Mon-Fri 08:00-17:00, Europe/Prague)), we want to
> use Olson's database names. If I understand it right, "UTC" is in Olson's and
> stands for UTC+0 offset. If not, we can have "UTC" keyword in the anchor part
> of the tuple mentioned above to signalize just that (UTC+0).