[Freeipa-devel] Time-based account policies

[Jan Cholasta]

Dne 24.3.2015 v 19:20 Simo Sorce napsal(a):
> On Tue, 2015-03-24 at 08:40 +0100, Martin Kosek wrote:
>> 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.
>>
>> 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
>>
>> 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...
>>
>
> Host Based Access Control is about controlling access based on the
> *HOST*.

Except you can control access based on user identity or group membership 
with HBAC.

>
> I do not see any space for user time zones honestly.

Well, I don't see what's so interesting about host time. Users have 
bussiness hours, hosts don't. Users can move between time zones by 
themselves, hosts can't.

>
> If and when someone will vehemently ask for 'per-user' time zones we can
> talk about it.
>
> Simo.
>


-- 
Jan Cholasta