[Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/25/2015 12:09 PM, Stanislav Láznička wrote:
> On 03/25/2015 08:21 AM, Jan Cholasta wrote:
>> Dne 24.3.2015 v 18:08 Stanislav Láznička napsal(a):
>>> 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.
>>
>> Timezones or not, there is always the responsibility of keeping LDAP in sync
>> with reality. I'm just saying there are possibilities besides doing it manually.
>>
>> Anyway, I think both user-local and host-local time can also be implemented
>> based on group membership, without storing anything with user and host
>> object, with HBAC rules like this:
>>
>>   Rule name: allow_tz_europe_prague_users
>>   Member groups: tz_europe_prague
>>   Host category: all
>>   Service category: all
>>   Access time: (timeofday=0800-1600 dayofweek=Mon-Fri)
>>   Time zone: Europe/Prague
>>   Description: Allow users in Europe/Prague access during bussiness hours
>>   Enabled: TRUE
>>
>>   Rule name: allow_tz_europe_prague_hosts
>>   User category: all
>>   Member hostgroups: tz_europe_prague
>>   Service category: all
>>   Access time: (timeofday=0800-1600 dayofweek=Mon-Fri)
>>   Time zone: Europe/Prague
>>   Description: Allow access to hosts in Europe/Prague during bussiness hours
>>   Enabled: TRUE
>>
>> I guess things might get complicated if you want to do limit access based on
>> both user and host local time, but I'm not sure if anyone would actually want
>> to do that.
>>
> This is great and it's how I would expect it would be performed. Although, I
> think it would still be good having host-local time rules enforced by the
> hosts' /etc/localtime. I'm not sure but I think that would still need to have
> the host's timezone stored for HBAC Test sake, is that right? That would be
> leading back to this solution as easiest, I guess.

I guess so. BTW, also check the latest Simo's note, user-based local time rules
may be something that does not fully fit in the HBAC scheme and may be
postponed or canceled.