[Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Wed, 25 Mar 2015, 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.
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.
-- 
/ Alexander Bokovoy