[Freeipa-devel] Time-based account policies

[Stanislav Láznička]

On 03/24/2015 08:53 AM, Jan Cholasta wrote:
> Dne 24.3.2015 v 08:40 Martin Kosek napsal(a):
>> On 03/24/2015 08:20 AM, Jakub Hrozek wrote:
>>> On Tue, Mar 24, 2015 at 08:07:53AM +0100, Martin Kosek wrote:
>>>> On 03/24/2015 07:16 AM, Jan Cholasta wrote:
>>>>> Dne 23.3.2015 v 20:17 Standa Láznička napsal(a):
>>>> ...
>>>>>>> Given the above, HBAC rules could contain (time, anchor), where 
>>>>>>> anchor
>>>>>>> is "UTC", "user local time" or "host local time".
>>>>>> Truth is, it was not really clear to me from the last week's 
>>>>>> discussion
>>>>>> whose "Local Time" to use - do we use host's or do we use 
>>>>>> user's?  It
>>>>>> would make sense to me to use the user's local time. But then you 
>>>>>> would
>>>>>> need to really store at least the timezone information with each 
>>>>>> user
>>>>>> object. And that information should probably change with user moving
>>>>>> between different timezones. That's quite a pickle I am in right 
>>>>>> here.
>>>>>
>>>>> IMO whether to use user or host local time depends on organization 
>>>>> local
>>>>> policy, hence my suggestion to support both.
>>>>
>>>> I am bit confused, I would like to make sure we are on the same 
>>>> page with
>>>> regards to Local Time. When the Local Time rule is created, anchor 
>>>> will be set
>>>> to "Local Time". Then SSSD would simply use host's local time, in 
>>>> whichever
>>>> time zone the HBAC host is.
>>>
>>> Yes, that was my understanding also.
>>>
>>>>
>>>> So this is the default host enforcement. For the user, you want to 
>>>> let SSSD
>>>> check authenticated user's entry, to see if there is a timezone 
>>>> information?
>>>> This would of course depend on the information being available. For 
>>>> AD users,
>>>> you would need to set it in ID Views or similar.
>>>
>>> Yes, also in a previous e-mail, there was a suggestion to change
>>> timezones by admin when the user changes timezones -- I didn't like 
>>> that
>>> part, it seems really error prone and tedious. *If* there was this
>>> choice, it should not be the default, rather the default should also be
>>> host local time IMO.
>
> I don't think you can expect host-local time to be good enough for 
> everyone.
>
>>
>> Host local time zone was the original case I expected. Enforcing 
>> *user* local
>> time zone is where this discussion started. Honze proposed making 
>> this an
>> option - leaving us to 3 different time modes:
>>
>> * UTC - stored as (time + olson time zone), enforcement is clear
>> * Host Local Time - stored as  (time + Host Local Time), enforcement by
>> /etc/localtime
>> * User Local Time - stored as  (time + User Local Time), enforcement 
>> by ???
>>
>> So the rule may be:
>> * Employee Foo can access web service Bar only in his work hours
>
> Correct.
>
>>
>> IMO, it is realistic for an administrator to set the time zone 
>> setting in the
>> employee entry. Of course, it gets tricky when the user starts moving 
>> around
>> the globe...
>>
>
> It doesn't have to be the administrator, it can be automated by a 3rd 
> party service:
>
>  1. Employee schedules bussiness trip in time management system
>  2. Manager approves the bussiness trip in the time management system
>  3. The time management system takes care of changing the employee's 
> user object timezone when the bussiness trip starts and ends.
>
I have to say I am not very sure about this anymore. Although it would 
be a great feature to have users' local time policies, it brings a lot 
of traps on the way. The responsibility of keeping the LDAP database 
consistent with reality is laid to a 3rd party application. If that 
breaks or does not work well, this responsibility might be sometimes 
transferred to admin. But if there's a lot of people traveling at a 
time... I'm having mixed feelings about this.