Re: [Freeipa-devel] Time-Based Account Policies

[Petr Vobornik]

On 08/03/2015 04:30 PM, Alexander Bokovoy wrote:

On Mon, 03 Aug 2015, Stanislav Laznicka wrote:







3. The mockups for HBAC time policies show quite a wizard-like UI.
While I might be very wrong here, I was thinking of rather a simple
UI where user would be able to set the values for each of the rule
keywords (timeofday, dayofweek, ...) directly in some text input
fields with possible help of JavaScript, that would add text
description to the user input (e.g. "Monday to Friday" with user
input "1-5" at the dayofweek input field).

With JavaScript support your wizard-like approach would still work
within the same page -- instead of moving 'next', you would need to
modify a number of available input fields based on selected items.
That's possible and I don't see much of trouble with it.


4. Do we want some special settings for "absolute" time policies
(policies that start and end at certain time in year)? The issue now
would be that some of such rules would have to be broken down in
more than one time rule (e.g. rule starting at a certain time of a
day in a month in one year and ending at a certain time, day and
month of a different year might get broken down to up to 6 rules if
I count right). This could actually be solved by a UI wizard-like
setting where the user gets to pick the dates and times of the rule,
a conversion method would need to be created and such a thing would
then work for the CLI, too. Still, usually more than one time rule
would be created for such cases.

Same here.


I might not have expressed myself clearly there, for which I am sorry.
I was rather thinking that instead of different 'screens' for
different time scenarios, like "Yearly", "Daily", etc., user should be
able to set all the values in one UI pop-up screen directly as number
values in text fields (with the exception of "absolute" time policies,
perhaps). While the user experience may suffer a bit, to me it seems
more clear, readable and flexible than to have some elements such as
checkboxes and selects take care of that (although the values around
the "interval" from iCalendar discussed here earlier would probably
need just that). Hopefully, I made myself clearer here :)

If you are able to structure types of scenarios clearly, use accordion
pattern to present them at the top level, like here:
https://www.patternfly.org/widgets/#accordion (we are using PatternFly
in our UI). Do per-scenario options in each panel as needed.



Better to ask UX developer for an opinion ;) (Kyle CCd)
--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies

[Stanislav Laznicka]

On 08/03/2015 04:30 PM, Alexander Bokovoy wrote:

On Mon, 03 Aug 2015, Stanislav Laznicka wrote:
dragons may appear, although with a tiny tiny possibility of a 
golden treasure in the end.

Yes, I think intervals are required.

Alright. I gave it a little thought considering the current state of 
the language for time rules and considering where I should go with 
these intervals. The thing about the 'interval' in iCalendar is that 
to use it it is necessary to also add at least the 'frequency' and 
'startdate' elements to the language. With that, adding 'enddate' and 
'count' optional elements should not be that bad. What I am hoping 
for is that the same functionality as in iCalendar can be achieved 
here and so far I do not see why not.

Yep.
So I have been struggling with this for some time but I hopefully have a 
solution now. As for the language, I suggest using a new keyword with 
possible values as in following:


repeat=date1(-date2)?\+[1-9][0-9]*(d|w|m|y)(:[1-9][0-9]*)?

Here, the date1 and optional date2 are dates in format MMDD and 
stand for the start and end dates.
The number after + denotes the repetition interval and d/w/m/y stand for 
day/week/month/year periods respectively. I am omitting the SECONDLY, 
MINUTELY and HOURLY frequencies from iCalendar as I don't consider them 
appropriate for our purpose. Besides, if "repeat" is not set, the 
behavior is similar as with freq=SECONDLY. The number in the optional 
part with ':' stands for the iCalendar COUNT feature. **However**, I do 
not think the COUNT feature should be included in this implementation. 
It probably makes sense as far as the generating of "time events" 
(single occurences in time) goes, but in the context of time policies it 
seems quite confusing to me. Here are some reasons why I think it should 
not be included:


1. Suppose you want to set, say, something like freq=DAILY;count=100; 
with timeofday=0730-1600. Such range ends at 9:10 the first day and 
setting time with any freq+count combination would not therefore make 
much sense. Yes, omitting the time from COUNT would be possible 
solution, yet it is a different behavior as in iCalendar.


2. You want to set some really complex time policy that should repeat 
for certain amount of times. To me, it seems safer to set a certain 
fixed final date rather than have it automagically decided for you.


3. The code would get messier with COUNT included. Currently, the time 
policies are evaluated as they are parsed without the need of storing 
them. With COUNT, they will need to be stored and also, before the 
actual evaluation, the events would need to be generated which can be 
hard with more complex policies (is it possible to set an event that 
would never happen, yet each part describing it would be correct?).


4. Not including COUNT in implementation is not a blocker from importing 
from the iCalendar format. If anything, COUNT just allows generating a 
finite set of events. During the import, the last event of such set can 
be either counted and filled in as end date, or the events can just be 
imported one by one.


Do you consider such a solution passable?
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies

[Alexander Bokovoy]

On Mon, 03 Aug 2015, Stanislav Laznicka wrote:
dragons may appear, although with a tiny tiny possibility of a 
golden treasure in the end.

Yes, I think intervals are required.

Alright. I gave it a little thought considering the current state of 
the language for time rules and considering where I should go with 
these intervals. The thing about the 'interval' in iCalendar is that 
to use it it is necessary to also add at least the 'frequency' and 
'startdate' elements to the language. With that, adding 'enddate' and 
'count' optional elements should not be that bad. What I am hoping for 
is that the same functionality as in iCalendar can be achieved here 
and so far I do not see why not.

Yep.

3. The mockups for HBAC time policies show quite a wizard-like UI. 
While I might be very wrong here, I was thinking of rather a 
simple UI where user would be able to set the values for each of 
the rule keywords (timeofday, dayofweek, ...) directly in some 
text input fields with possible help of JavaScript, that would add 
text description to the user input (e.g. "Monday to Friday" with 
user input "1-5" at the dayofweek input field).

With JavaScript support your wizard-like approach would still work
within the same page -- instead of moving 'next', you would need to
modify a number of available input fields based on selected items.
That's possible and I don't see much of trouble with it.

4. Do we want some special settings for "absolute" time policies 
(policies that start and end at certain time in year)? The issue 
now would be that some of such rules would have to be broken down 
in more than one time rule (e.g. rule starting at a certain time 
of a day in a month in one year and ending at a certain time, day 
and month of a different year might get broken down to up to 6 
rules if I count right). This could actually be solved by a UI 
wizard-like setting where the user gets to pick the dates and 
times of the rule, a conversion method would need to be created 
and such a thing would then work for the CLI, too. Still, usually 
more than one time rule would be created for such cases.

Same here.

I might not have expressed myself clearly there, for which I am sorry. 
I was rather thinking that instead of different 'screens' for 
different time scenarios, like "Yearly", "Daily", etc., user should be 
able to set all the values in one UI pop-up screen directly as number 
values in text fields (with the exception of "absolute" time policies, 
perhaps). While the user experience may suffer a bit, to me it seems 
more clear, readable and flexible than to have some elements such as 
checkboxes and selects take care of that (although the values around 
the "interval" from iCalendar discussed here earlier would probably 
need just that). Hopefully, I made myself clearer here :)

If you are able to structure types of scenarios clearly, use accordion
pattern to present them at the top level, like here:
https://www.patternfly.org/widgets/#accordion (we are using PatternFly
in our UI). Do per-scenario options in each panel as needed.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies

[Stanislav Laznicka]

On 08/03/2015 11:45 AM, Alexander Bokovoy wrote:

On Mon, 03 Aug 2015, Stanislav Laznicka wrote:

Hi,

I have made some changes to the structure of the HBAC time rules 
extension, namely the code that validates the time rules' strings was 
moved from the ipalib/parameters to the hbacrule module itself, and a 
more "fresh" approach was used in code for methods of adding/removing 
time policies to HBAC rules.

Thanks for the advances. :)

A slight change was made to understanding a week in a month. The 
change follows the Java implementation of a week in a month as 
suggested by Petr V., given a week starts on Monday (=1; iso 8601). 
More on that on the previously mentioned link


https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html 



What this change means is that a first week in a month is a week that 
contains at least 4 days. If it has less days, it's 0-th week 
(probably better than having it belong to the previous month as some 
sources also suggest - iso 8601 does not have a definition for a week 
in month but it has a definition for a week in a year).

Sounds fine.

I had Jan C. check the current implementation of the FreeIPA side for 
the time-based policies and it seems to work as is. He created 
official number identifiers for the 2 new LDAP attributeTypes, too. \o/


I was also going through some old mockups for the WebUI Petr V. sent 
me earlier last month. It brought some questions worth sharing here.


1. Do we need time rules based on the day and week of the year? 
Currently, there is no such option as dayofyear or weekofyear in the 
rules language, although adding it should not be that much of a 
problem. I did not include them as it seemed more convenient to set 
the data as combinations of dayofmonth and monthofyear values.

In business circles it is increasingly common to refer to events by
their week numbers, especially in logistics and factory delivery.

See http://www.cl.cam.ac.uk/~mgk25/iso-time.html for some details at the
end of 'Date' section.


It should go right in, then.


2. Should we add dayofyear and weekofyear, a possible need for 
"intervals" might be required. An "interval" is a behavior from the 
iCalendar format. It basically functions as range() in Python, 
although with possible 'infinite' end. Example: should you have a 
recurrence rule on daily basis with interval=2, a rule would apply on 
every other day. This is kind of a question of keeping it easy and 
light or heading a way of robust implementation during which dragons 
may appear, although with a tiny tiny possibility of a golden 
treasure in the end.

Yes, I think intervals are required.

Alright. I gave it a little thought considering the current state of the 
language for time rules and considering where I should go with these 
intervals. The thing about the 'interval' in iCalendar is that to use it 
it is necessary to also add at least the 'frequency' and 'startdate' 
elements to the language. With that, adding 'enddate' and 'count' 
optional elements should not be that bad. What I am hoping for is that 
the same functionality as in iCalendar can be achieved here and so far I 
do not see why not.
3. The mockups for HBAC time policies show quite a wizard-like UI. 
While I might be very wrong here, I was thinking of rather a simple 
UI where user would be able to set the values for each of the rule 
keywords (timeofday, dayofweek, ...) directly in some text input 
fields with possible help of JavaScript, that would add text 
description to the user input (e.g. "Monday to Friday" with user 
input "1-5" at the dayofweek input field).

With JavaScript support your wizard-like approach would still work
within the same page -- instead of moving 'next', you would need to
modify a number of available input fields based on selected items.
That's possible and I don't see much of trouble with it.

4. Do we want some special settings for "absolute" time policies 
(policies that start and end at certain time in year)? The issue now 
would be that some of such rules would have to be broken down in more 
than one time rule (e.g. rule starting at a certain time of a day in 
a month in one year and ending at a certain time, day and month of a 
different year might get broken down to up to 6 rules if I count 
right). This could actually be solved by a UI wizard-like setting 
where the user gets to pick the dates and times of the rule, a 
conversion method would need to be created and such a thing would 
then work for the CLI, too. Still, usually more than one time rule 
would be created for such cases.

Same here.

I might not have expressed myself clearly there, for which I am sorry. I 
was rather thinking that instead of different 'screens' for different 
time scenarios, like "Yearly", "Daily", etc., user should be able to set 
all the values in one UI pop-up screen directly as number values in text 
fields (with the exception of "absolute" time policies, perhaps). While 
the user experience may s

Re: [Freeipa-devel] Time-Based Account Policies

[Alexander Bokovoy]

On Mon, 03 Aug 2015, Stanislav Laznicka wrote:

Hi,

I have made some changes to the structure of the HBAC time rules 
extension, namely the code that validates the time rules' strings was 
moved from the ipalib/parameters to the hbacrule module itself, and a 
more "fresh" approach was used in code for methods of adding/removing 
time policies to HBAC rules.

Thanks for the advances. :)

A slight change was made to understanding a week in a month. The 
change follows the Java implementation of a week in a month as 
suggested by Petr V., given a week starts on Monday (=1; iso 8601). 
More on that on the previously mentioned link


https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html

What this change means is that a first week in a month is a week that 
contains at least 4 days. If it has less days, it's 0-th week 
(probably better than having it belong to the previous month as some 
sources also suggest - iso 8601 does not have a definition for a week 
in month but it has a definition for a week in a year).

Sounds fine.

I had Jan C. check the current implementation of the FreeIPA side for 
the time-based policies and it seems to work as is. He created 
official number identifiers for the 2 new LDAP attributeTypes, too. 
\o/


I was also going through some old mockups for the WebUI Petr V. sent 
me earlier last month. It brought some questions worth sharing here.


1. Do we need time rules based on the day and week of the year? 
Currently, there is no such option as dayofyear or weekofyear in the 
rules language, although adding it should not be that much of a 
problem. I did not include them as it seemed more convenient to set 
the data as combinations of dayofmonth and monthofyear values.

In business circles it is increasingly common to refer to events by
their week numbers, especially in logistics and factory delivery.

See http://www.cl.cam.ac.uk/~mgk25/iso-time.html for some details at the
end of 'Date' section.


2. Should we add dayofyear and weekofyear, a possible need for 
"intervals" might be required. An "interval" is a behavior from the 
iCalendar format. It basically functions as range() in Python, 
although with possible 'infinite' end. Example: should you have a 
recurrence rule on daily basis with interval=2, a rule would apply on 
every other day. This is kind of a question of keeping it easy and 
light or heading a way of robust implementation during which dragons 
may appear, although with a tiny tiny possibility of a golden treasure 
in the end.

Yes, I think intervals are required.

3. The mockups for HBAC time policies show quite a wizard-like UI. 
While I might be very wrong here, I was thinking of rather a simple UI 
where user would be able to set the values for each of the rule 
keywords (timeofday, dayofweek, ...) directly in some text input 
fields with possible help of JavaScript, that would add text 
description to the user input (e.g. "Monday to Friday" with user input 
"1-5" at the dayofweek input field).

With JavaScript support your wizard-like approach would still work
within the same page -- instead of moving 'next', you would need to
modify a number of available input fields based on selected items.
That's possible and I don't see much of trouble with it.

4. Do we want some special settings for "absolute" time policies 
(policies that start and end at certain time in year)? The issue now 
would be that some of such rules would have to be broken down in more 
than one time rule (e.g. rule starting at a certain time of a day in a 
month in one year and ending at a certain time, day and month of a 
different year might get broken down to up to 6 rules if I count 
right). This could actually be solved by a UI wizard-like setting 
where the user gets to pick the dates and times of the rule, a 
conversion method would need to be created and such a thing would then 
work for the CLI, too. Still, usually more than one time rule would be 
created for such cases.

Same here.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] Time-Based Account Policies

[Stanislav Laznicka]

Hi,

I have made some changes to the structure of the HBAC time rules 
extension, namely the code that validates the time rules' strings was 
moved from the ipalib/parameters to the hbacrule module itself, and a 
more "fresh" approach was used in code for methods of adding/removing 
time policies to HBAC rules.


A slight change was made to understanding a week in a month. The change 
follows the Java implementation of a week in a month as suggested by 
Petr V., given a week starts on Monday (=1; iso 8601). More on that on 
the previously mentioned link


https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html

What this change means is that a first week in a month is a week that 
contains at least 4 days. If it has less days, it's 0-th week (probably 
better than having it belong to the previous month as some sources also 
suggest - iso 8601 does not have a definition for a week in month but it 
has a definition for a week in a year).


I had Jan C. check the current implementation of the FreeIPA side for 
the time-based policies and it seems to work as is. He created official 
number identifiers for the 2 new LDAP attributeTypes, too. \o/


I was also going through some old mockups for the WebUI Petr V. sent me 
earlier last month. It brought some questions worth sharing here.


1. Do we need time rules based on the day and week of the year? 
Currently, there is no such option as dayofyear or weekofyear in the 
rules language, although adding it should not be that much of a problem. 
I did not include them as it seemed more convenient to set the data as 
combinations of dayofmonth and monthofyear values.


2. Should we add dayofyear and weekofyear, a possible need for 
"intervals" might be required. An "interval" is a behavior from the 
iCalendar format. It basically functions as range() in Python, although 
with possible 'infinite' end. Example: should you have a recurrence rule 
on daily basis with interval=2, a rule would apply on every other day. 
This is kind of a question of keeping it easy and light or heading a way 
of robust implementation during which dragons may appear, although with 
a tiny tiny possibility of a golden treasure in the end.


3. The mockups for HBAC time policies show quite a wizard-like UI. While 
I might be very wrong here, I was thinking of rather a simple UI where 
user would be able to set the values for each of the rule keywords 
(timeofday, dayofweek, ...) directly in some text input fields with 
possible help of JavaScript, that would add text description to the user 
input (e.g. "Monday to Friday" with user input "1-5" at the dayofweek 
input field).


4. Do we want some special settings for "absolute" time policies 
(policies that start and end at certain time in year)? The issue now 
would be that some of such rules would have to be broken down in more 
than one time rule (e.g. rule starting at a certain time of a day in a 
month in one year and ending at a certain time, day and month of a 
different year might get broken down to up to 6 rules if I count right). 
This could actually be solved by a UI wizard-like setting where the user 
gets to pick the dates and times of the rule, a conversion method would 
need to be created and such a thing would then work for the CLI, too. 
Still, usually more than one time rule would be created for such cases.


Thanks for keeping up with me and my long emails. I am a terrible person 
for that and I hope I will be able to cut them short in the future.


Cheers,
Standa
From 4f25d320d9a31707bf7d0b55ea28b7e223e09f70 Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Tue, 7 Jul 2015 09:44:23 +0200
Subject: [PATCH 1/3] Added time-based policies types to LDAP schema.

https://fedorahosted.org/freeipa/ticket/547
https://fedorahosted.org/freeipa/ticket/548
---
 install/share/60basev2.ldif | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/install/share/60basev2.ldif b/install/share/60basev2.ldif
index 00712ddda2c548b7f7924a012f3f68499f2f01da..c3251a4331005ade1333f9e64b57a62a89706ce9 100644
--- a/install/share/60basev2.ldif
+++ b/install/share/60basev2.ldif
@@ -37,7 +37,9 @@ attributeTypes: (2.16.840.1.113730.3.8.3.11 NAME 'externalHost' DESC 'Multivalue
 attributeTypes: (2.16.840.1.113730.3.8.3.12 NAME 'sourceHostCategory' DESC 'Additional classification for hosts' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' )
 attributeTypes: (2.16.840.1.113730.3.8.3.13 NAME 'accessRuleType' DESC 'The flag to represent if it is allow or deny rule.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' )
 attributeTypes: (2.16.840.1.113730.3.8.3.14 NAME 'accessTime' DESC 'Access time' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' )
-objectClasses: (2

Re: [Freeipa-devel] Time-Based Account Policies

[Stanislav Laznicka]

On 07/10/2015 04:17 PM, Martin Basti wrote:

On 10/07/15 12:08, Stanislav Laznicka wrote:

Hi,

Long time no post from me, time to make it up to you.

I have been working on the the implementation of the design of time 
policies for HBAC rules on FreeIPA and SSSD sides. Attached is the 
current state of the FreeIPA solution. My comments and notes to the 
solution follow.


The FreeIPA side backend base for time policies in HBAC seems working 
to me but still needs formal testing. Also, there is no conversion 
from the iCal format as previously requested and I personally would 
postpone this feature until the time policies functionality is rock 
solid.


There were some uncertainties in the design as well. I ran into 2 of 
these but more may come.


The first thing is how to deal with weeks in a month. There are two 
possibilities. A week in month (as specified by the weekofmonth 
keyword in the time policies) may be understood as a period of time 
between two Sundays, so when a month starts on, say, Friday the 1st, 
weekofmonth=1 would specify days Friday, Saturday, Sunday and 
anything from that Sunday on would be a weekofmonth=2 and on. 
However, I think a week in a month may also be considered a period of 
time that equals 7 days of a month. In the previous example, a 
weekofmonth=1 would therefore also apply to the following days up 
until Friday the 8th, excluding this last day. Although I implemented 
the first case in the SSSD, I actually started thinking the second 
case scenario might be the right or "better" one.


The other thing is which years should be allowed to be the input of 
the "year" keyword. Currently, I set the range for these values to 
1970-2038 according to the Unix timestamp. I'm not sure if anyone 
would want to set it less than 1970, setting it for a higher value 
than 2038 might probably make sense in some very special cases, 
although I really can't think of a one.


As for the WebUI, I am not really satisfied with the current state - 
the time zone select button requires saving the rule before any 
further setting on the page and the tables for setting the time rules 
don't allow editing the rules, which gets annoying fast. The WebUI 
for the time policies in HBAC was created for my Master's thesis 
purposes in a hurry and I will probably need to discuss it some more 
with Petr V. It works well for basic display and add/remove of the 
time rules, though.


So, that is what I do now, aside from SSSD functionality. Please, let 
me know what your ideas are, especially about those weekofmonth and 
year issues.


Cheers,
Stanislav Laznicka


Please revert this change, 'replaces' keyword is used only for legacy 
permission. Changes in new permissions are handled automatically by 
update plugin.


  'replaces': [
-'(targetattr = "servicecategory || sourcehostcategory || cn || description || ipaenabledflag || 
accesstime || usercategory || hostcategory || accessruletype || sourcehost")(target 
="ldap:///ipauniqueid=*,cn=hbac,$SUFFIX";)(version 3.0;acl "permission:Modify HBAC rule";allow 
(write) groupdn ="ldap:///cn=Modify HBAC rule,cn=permissions,cn=pbac,$SUFFIX";)',
+'(targetattr = "servicecategory || sourcehostcategory || cn || description || ipaenabledflag || 
timezone || accesstime || accesstimeexclude || usercategory || hostcategory || accessruletype || 
sourcehost")(target ="ldap:///ipauniqueid=*,cn=hbac,$SUFFIX";)(version 3.0;acl "permission:Modify 
HBAC rule";allow (write) groupdn ="ldap:///cn=Modify HBAC rule,cn=permissions,cn=pbac,$SUFFIX";)',
  ],

Martin
--
Martin Basti

Attaching the sequence of fixed patches.
From 3bd1b08e00417d32138dbe7e92536b474f62fc8b Mon Sep 17 00:00:00 2001
From: Stanislav Laznicka 
Date: Tue, 7 Jul 2015 09:44:23 +0200
Subject: [PATCH 1/4] Added time-based policies types to LDAP schema.

https://fedorahosted.org/freeipa/ticket/547
https://fedorahosted.org/freeipa/ticket/548
---
 install/share/60basev2.ldif | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/install/share/60basev2.ldif b/install/share/60basev2.ldif
index 00712ddda2c548b7f7924a012f3f68499f2f01da..846c304264e3d9af9eeb293e4a8178282dc4958c 100644
--- a/install/share/60basev2.ldif
+++ b/install/share/60basev2.ldif
@@ -37,7 +37,9 @@ attributeTypes: (2.16.840.1.113730.3.8.3.11 NAME 'externalHost' DESC 'Multivalue
 attributeTypes: (2.16.840.1.113730.3.8.3.12 NAME 'sourceHostCategory' DESC 'Additional classification for hosts' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' )
 attributeTypes: (2.16.840.1.113730.3.8.3.13 NAME 'accessRuleType' DESC 'The flag to represent if it is allow or deny rule.' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v2' )
 attributeTypes: (2.16.840.1.113730.3.8.3.14 NAME 'accessTime' DESC 'Access t

Re: [Freeipa-devel] Time-Based Account Policies

[Martin Basti]

On 10/07/15 12:08, Stanislav Laznicka wrote:

Hi,

Long time no post from me, time to make it up to you.

I have been working on the the implementation of the design of time 
policies for HBAC rules on FreeIPA and SSSD sides. Attached is the 
current state of the FreeIPA solution. My comments and notes to the 
solution follow.


The FreeIPA side backend base for time policies in HBAC seems working 
to me but still needs formal testing. Also, there is no conversion 
from the iCal format as previously requested and I personally would 
postpone this feature until the time policies functionality is rock 
solid.


There were some uncertainties in the design as well. I ran into 2 of 
these but more may come.


The first thing is how to deal with weeks in a month. There are two 
possibilities. A week in month (as specified by the weekofmonth 
keyword in the time policies) may be understood as a period of time 
between two Sundays, so when a month starts on, say, Friday the 1st, 
weekofmonth=1 would specify days Friday, Saturday, Sunday and anything 
from that Sunday on would be a weekofmonth=2 and on. However, I think 
a week in a month may also be considered a period of time that equals 
7 days of a month. In the previous example, a weekofmonth=1 would 
therefore also apply to the following days up until Friday the 8th, 
excluding this last day. Although I implemented the first case in the 
SSSD, I actually started thinking the second case scenario might be 
the right or "better" one.


The other thing is which years should be allowed to be the input of 
the "year" keyword. Currently, I set the range for these values to 
1970-2038 according to the Unix timestamp. I'm not sure if anyone 
would want to set it less than 1970, setting it for a higher value 
than 2038 might probably make sense in some very special cases, 
although I really can't think of a one.


As for the WebUI, I am not really satisfied with the current state - 
the time zone select button requires saving the rule before any 
further setting on the page and the tables for setting the time rules 
don't allow editing the rules, which gets annoying fast. The WebUI for 
the time policies in HBAC was created for my Master's thesis purposes 
in a hurry and I will probably need to discuss it some more with Petr 
V. It works well for basic display and add/remove of the time rules, 
though.


So, that is what I do now, aside from SSSD functionality. Please, let 
me know what your ideas are, especially about those weekofmonth and 
year issues.


Cheers,
Stanislav Laznicka


Please revert this change, 'replaces' keyword is used only for legacy 
permission. Changes in new permissions are handled automatically by 
update plugin.


 'replaces': [
-'(targetattr = "servicecategory || sourcehostcategory || cn || description || ipaenabledflag || 
accesstime || usercategory || hostcategory || accessruletype || sourcehost")(target 
="ldap:///ipauniqueid=*,cn=hbac,$SUFFIX";)(version 3.0;acl "permission:Modify HBAC rule";allow 
(write) groupdn ="ldap:///cn=Modify HBAC rule,cn=permissions,cn=pbac,$SUFFIX";)',
+'(targetattr = "servicecategory || sourcehostcategory || cn || description || ipaenabledflag || 
timezone || accesstime || accesstimeexclude || usercategory || hostcategory || accessruletype || 
sourcehost")(target ="ldap:///ipauniqueid=*,cn=hbac,$SUFFIX";)(version 3.0;acl "permission:Modify 
HBAC rule";allow (write) groupdn ="ldap:///cn=Modify HBAC rule,cn=permissions,cn=pbac,$SUFFIX";)',
 ],


Martin

--
Martin Basti

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies

[Stanislav Laznicka]

On 07/10/2015 01:12 PM, Matúš Honěk wrote:

On 07/10/2015 12:43 PM, Alexander Bokovoy wrote:

On Fri, 10 Jul 2015, Stanislav Laznicka wrote:

Hi,

Long time no post from me, time to make it up to you.

Welcome back!


I have been working on the the implementation of the design of time
policies for HBAC rules on FreeIPA and SSSD sides. Attached is the
current state of the FreeIPA solution. My comments and notes to the
solution follow.

The FreeIPA side backend base for time policies in HBAC seems working
to me but still needs formal testing. Also, there is no conversion
from the iCal format as previously requested and I personally would
postpone this feature until the time policies functionality is rock
solid.

There were some uncertainties in the design as well. I ran into 2 of
these but more may come.

The first thing is how to deal with weeks in a month. There are two
possibilities. A week in month (as specified by the weekofmonth
keyword in the time policies) may be understood as a period of time
between two Sundays, so when a month starts on, say, Friday the 1st,
weekofmonth=1 would specify days Friday, Saturday, Sunday and anything
from that Sunday on would be a weekofmonth=2 and on. However, I think
a week in a month may also be considered a period of time that equals
7 days of a month. In the previous example, a weekofmonth=1 would
therefore also apply to the following days up until Friday the 8th,
excluding this last day. Although I implemented the first case in the
SSSD, I actually started thinking the second case scenario might be
the right or "better" one.

One thing you need to realize that there is no universal 'week starts on
Sunday'.
There are different ways of starting a week, some countries do it on
Sunday, some -- on Saturday, some -- on Monday. This means you need to
make possible to pull in a locale definition if you really want this
functionality and then it also becomes quite fuzzy as there are legal
definitions of what a week is (as well as a month and a work day).
I would definitely go with using the locales for deciding (same for 
weeks of year, etc.). With addition to that I would, personally, also 
make it clear to see the exact description of the policy currently in 
use, on the WebUI and CLI (if it is possible, of course). Maybe it is 
just me but I have no idea how to decide when is the first week of a 
month, even in my locale. (if it is already there then act as if I 
have said nothing)


I am not sure about using locales to decide on which day should start a 
week. It seems better to stick to only one certain day to avoid confusion.


I don't think it would be possible to have a note that says that this 
certain time policy applies at this certain time. It would be hard when 
only different time zones and UTC are taken into account, but the 
possibility to make time policy whose time zone is dependent purely on 
host's local time zone makes this impossible.


Petr V. posted a nice way of how to define a week earlier in this 
thread, even the first and 0-th week.



The other thing is which years should be allowed to be the input of
the "year" keyword. Currently, I set the range for these values to
1970-2038 according to the Unix timestamp. I'm not sure if anyone
would want to set it less than 1970, setting it for a higher value
than 2038 might probably make sense in some very special cases,
although I really can't think of a one.

You certainly can set it more than 2038 (time doesn't stop there). What
you are limited with is Kerberos 32-bit time stamp, not HBAC policy time
definition. I would say we better set to 64-bit ourselves and handle
irregularities in SSSD.





--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies

[Stanislav Laznicka]

On 07/10/2015 01:10 PM, Petr Vobornik wrote:

On 07/10/2015 12:43 PM, Alexander Bokovoy wrote:

On Fri, 10 Jul 2015, Stanislav Laznicka wrote:

Hi,

Long time no post from me, time to make it up to you.

Welcome back!


I have been working on the the implementation of the design of time
policies for HBAC rules on FreeIPA and SSSD sides. Attached is the
current state of the FreeIPA solution. My comments and notes to the
solution follow.

The FreeIPA side backend base for time policies in HBAC seems working
to me but still needs formal testing. Also, there is no conversion
from the iCal format as previously requested and I personally would
postpone this feature until the time policies functionality is rock
solid.

There were some uncertainties in the design as well. I ran into 2 of
these but more may come.

The first thing is how to deal with weeks in a month. There are two
possibilities. A week in month (as specified by the weekofmonth
keyword in the time policies) may be understood as a period of time
between two Sundays, so when a month starts on, say, Friday the 1st,
weekofmonth=1 would specify days Friday, Saturday, Sunday and anything
from that Sunday on would be a weekofmonth=2 and on. However, I think
a week in a month may also be considered a period of time that equals
7 days of a month. In the previous example, a weekofmonth=1 would
therefore also apply to the following days up until Friday the 8th,
excluding this last day. Although I implemented the first case in the
SSSD, I actually started thinking the second case scenario might be
the right or "better" one.

One thing you need to realize that there is no universal 'week starts on
Sunday'.
There are different ways of starting a week, some countries do it on
Sunday, some -- on Saturday, some -- on Monday. This means you need to
make possible to pull in a locale definition if you really want this
functionality and then it also becomes quite fuzzy as there are legal
definitions of what a week is (as well as a month and a work day).



Yes, it could be more complicated, e.g. see Week Of Month in Java:
"""
week-of-month: The calculation ensures that weeks never overlap a 
month boundary. The month is divided into periods where each period 
starts on the defined first day-of-week. The earliest period is 
referred to as week 0 if it has less than the minimal number of days 
and week 1 if it has at least the minimal number of days.



public int getMinimalDaysInFirstWeek():

Gets the minimal number of days in the first week.

The number of days considered to define the first week of a month or 
year varies by culture. For example, the ISO-8601 requires 4 days 
(more than half a week) to be present before counting the first week.

"""
https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html 




That is a pretty good example of what a week is, thanks.

I don't think I would want the functionality of having weeks begin with 
different weekdays according to locale. I would rather stick to the ISO 
8601 as described in the link Petr sent. I was rather wondering whether 
weekofmonth should mean the x-th appearance of a day in a month or an 
appearance of this day in x-th week of the month. However, the 
definition above is quite strong and I think I could live with a week 
starting only on Monday and having 0-th weeks in month.

The other thing is which years should be allowed to be the input of
the "year" keyword. Currently, I set the range for these values to
1970-2038 according to the Unix timestamp. I'm not sure if anyone
would want to set it less than 1970, setting it for a higher value
than 2038 might probably make sense in some very special cases,
although I really can't think of a one.

You certainly can set it more than 2038 (time doesn't stop there). What
you are limited with is Kerberos 32-bit time stamp, not HBAC policy time
definition. I would say we better set to 64-bit ourselves and handle
irregularities in SSSD.



Yes, we should talk.

Some comments from looking on patch 0004:
1. list of time zones should be moved to a module property so that it 
can be reused else where if needed. Other possibility is to get this 
list from backend, e.g. on Web UI load or something.


2. please don't do any changes to patternfly.js. It's updated only 
when bundled PatternFly is updated. Long term goal is to get it out of 
FreeIPA git.


All IPA css changes should be done in install/ui/less/*less files - as 
you did in widgets.less. From these .less files an 
install/ui/css/ipa.css file is created. Note that there is also 
install/ui/ipa.css which contains most of the ipa specific styles. 
It's planned to move these styles to .less files as well.
I put those 2 last commits together, the only difference there was that 
once the styles were set correctly (0005) and incorrectly in the 
previous patch (0004). Attaching the last commit, also hopefully with 
correct formatting as pointed out by Martin Basti. I should add the list 
of time zone

Re: [Freeipa-devel] Time-Based Account Policies

[Matúš Honěk]

On 07/10/2015 12:43 PM, Alexander Bokovoy wrote:

On Fri, 10 Jul 2015, Stanislav Laznicka wrote:

Hi,

Long time no post from me, time to make it up to you.

Welcome back!


I have been working on the the implementation of the design of time
policies for HBAC rules on FreeIPA and SSSD sides. Attached is the
current state of the FreeIPA solution. My comments and notes to the
solution follow.

The FreeIPA side backend base for time policies in HBAC seems working
to me but still needs formal testing. Also, there is no conversion
from the iCal format as previously requested and I personally would
postpone this feature until the time policies functionality is rock
solid.

There were some uncertainties in the design as well. I ran into 2 of
these but more may come.

The first thing is how to deal with weeks in a month. There are two
possibilities. A week in month (as specified by the weekofmonth
keyword in the time policies) may be understood as a period of time
between two Sundays, so when a month starts on, say, Friday the 1st,
weekofmonth=1 would specify days Friday, Saturday, Sunday and anything
from that Sunday on would be a weekofmonth=2 and on. However, I think
a week in a month may also be considered a period of time that equals
7 days of a month. In the previous example, a weekofmonth=1 would
therefore also apply to the following days up until Friday the 8th,
excluding this last day. Although I implemented the first case in the
SSSD, I actually started thinking the second case scenario might be
the right or "better" one.

One thing you need to realize that there is no universal 'week starts on
Sunday'.
There are different ways of starting a week, some countries do it on
Sunday, some -- on Saturday, some -- on Monday. This means you need to
make possible to pull in a locale definition if you really want this
functionality and then it also becomes quite fuzzy as there are legal
definitions of what a week is (as well as a month and a work day).
I would definitely go with using the locales for deciding (same for 
weeks of year, etc.). With addition to that I would, personally, also 
make it clear to see the exact description of the policy currently in 
use, on the WebUI and CLI (if it is possible, of course). Maybe it is 
just me but I have no idea how to decide when is the first week of a 
month, even in my locale. (if it is already there then act as if I have 
said nothing)





The other thing is which years should be allowed to be the input of
the "year" keyword. Currently, I set the range for these values to
1970-2038 according to the Unix timestamp. I'm not sure if anyone
would want to set it less than 1970, setting it for a higher value
than 2038 might probably make sense in some very special cases,
although I really can't think of a one.

You certainly can set it more than 2038 (time doesn't stop there). What
you are limited with is Kerberos 32-bit time stamp, not HBAC policy time
definition. I would say we better set to 64-bit ourselves and handle
irregularities in SSSD.



--
Matúš Honěk

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies

[Petr Vobornik]

On 07/10/2015 12:43 PM, Alexander Bokovoy wrote:

On Fri, 10 Jul 2015, Stanislav Laznicka wrote:

Hi,

Long time no post from me, time to make it up to you.

Welcome back!


I have been working on the the implementation of the design of time
policies for HBAC rules on FreeIPA and SSSD sides. Attached is the
current state of the FreeIPA solution. My comments and notes to the
solution follow.

The FreeIPA side backend base for time policies in HBAC seems working
to me but still needs formal testing. Also, there is no conversion
from the iCal format as previously requested and I personally would
postpone this feature until the time policies functionality is rock
solid.

There were some uncertainties in the design as well. I ran into 2 of
these but more may come.

The first thing is how to deal with weeks in a month. There are two
possibilities. A week in month (as specified by the weekofmonth
keyword in the time policies) may be understood as a period of time
between two Sundays, so when a month starts on, say, Friday the 1st,
weekofmonth=1 would specify days Friday, Saturday, Sunday and anything
from that Sunday on would be a weekofmonth=2 and on. However, I think
a week in a month may also be considered a period of time that equals
7 days of a month. In the previous example, a weekofmonth=1 would
therefore also apply to the following days up until Friday the 8th,
excluding this last day. Although I implemented the first case in the
SSSD, I actually started thinking the second case scenario might be
the right or "better" one.

One thing you need to realize that there is no universal 'week starts on
Sunday'.
There are different ways of starting a week, some countries do it on
Sunday, some -- on Saturday, some -- on Monday. This means you need to
make possible to pull in a locale definition if you really want this
functionality and then it also becomes quite fuzzy as there are legal
definitions of what a week is (as well as a month and a work day).



Yes, it could be more complicated, e.g. see Week Of Month in Java:
"""
week-of-month: The calculation ensures that weeks never overlap a month 
boundary. The month is divided into periods where each period starts on 
the defined first day-of-week. The earliest period is referred to as 
week 0 if it has less than the minimal number of days and week 1 if it 
has at least the minimal number of days.



public int getMinimalDaysInFirstWeek():

Gets the minimal number of days in the first week.

The number of days considered to define the first week of a month or 
year varies by culture. For example, the ISO-8601 requires 4 days (more 
than half a week) to be present before counting the first week.

"""
https://docs.oracle.com/javase/8/docs/api/java/time/temporal/WeekFields.html


The other thing is which years should be allowed to be the input of
the "year" keyword. Currently, I set the range for these values to
1970-2038 according to the Unix timestamp. I'm not sure if anyone
would want to set it less than 1970, setting it for a higher value
than 2038 might probably make sense in some very special cases,
although I really can't think of a one.

You certainly can set it more than 2038 (time doesn't stop there). What
you are limited with is Kerberos 32-bit time stamp, not HBAC policy time
definition. I would say we better set to 64-bit ourselves and handle
irregularities in SSSD.



Yes, we should talk.

Some comments from looking on patch 0004:
1. list of time zones should be moved to a module property so that it 
can be reused else where if needed. Other possibility is to get this 
list from backend, e.g. on Web UI load or something.


2. please don't do any changes to patternfly.js. It's updated only when 
bundled PatternFly is updated. Long term goal is to get it out of 
FreeIPA git.


All IPA css changes should be done in install/ui/less/*less files - as 
you did in widgets.less. From these .less files an 
install/ui/css/ipa.css file is created. Note that there is also 
install/ui/ipa.css which contains most of the ipa specific styles. It's 
planned to move these styles to .less files as well.

--
Petr Vobornik

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies

[Alexander Bokovoy]

On Fri, 10 Jul 2015, Stanislav Laznicka wrote:

Hi,

Long time no post from me, time to make it up to you.

Welcome back!

I have been working on the the implementation of the design of time policies 
for HBAC rules on FreeIPA and SSSD sides. Attached is the current state of 
the FreeIPA solution. My comments and notes to the solution follow.


The FreeIPA side backend base for time policies in HBAC seems working to me 
but still needs formal testing. Also, there is no conversion from the iCal 
format as previously requested and I personally would postpone this feature 
until the time policies functionality is rock solid.


There were some uncertainties in the design as well. I ran into 2 of these 
but more may come.


The first thing is how to deal with weeks in a month. There are two 
possibilities. A week in month (as specified by the weekofmonth keyword in 
the time policies) may be understood as a period of time between two 
Sundays, so when a month starts on, say, Friday the 1st, weekofmonth=1 would 
specify days Friday, Saturday, Sunday and anything from that Sunday on would 
be a weekofmonth=2 and on. However, I think a week in a month may also be 
considered a period of time that equals 7 days of a month. In the previous 
example, a weekofmonth=1 would therefore also apply to the following days up 
until Friday the 8th, excluding this last day. Although I implemented the 
first case in the SSSD, I actually started thinking the second case scenario 
might be the right or "better" one.

One thing you need to realize that there is no universal 'week starts on 
Sunday'.
There are different ways of starting a week, some countries do it on
Sunday, some -- on Saturday, some -- on Monday. This means you need to
make possible to pull in a locale definition if you really want this
functionality and then it also becomes quite fuzzy as there are legal
definitions of what a week is (as well as a month and a work day).

The other thing is which years should be allowed to be the input of the 
"year" keyword. Currently, I set the range for these values to 1970-2038 
according to the Unix timestamp. I'm not sure if anyone would want to set it 
less than 1970, setting it for a higher value than 2038 might probably make 
sense in some very special cases, although I really can't think of a one.

You certainly can set it more than 2038 (time doesn't stop there). What
you are limited with is Kerberos 32-bit time stamp, not HBAC policy time
definition. I would say we better set to 64-bit ourselves and handle
irregularities in SSSD.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Alexander Bokovoy]

On Thu, 16 Apr 2015, Simo Sorce wrote:

On Thu, 2015-04-16 at 10:04 +0200, Stanislav Láznička wrote:

>> Possible values of each keyword:
>> timeofday   -2359
>> dayofweek   Mon, Tue, Wed, Thu, Fri, Sat, Sun
>> dayofmonth  1-31
>> weekofmonth 1-5
>> monthofyear Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct,
>> Nov, Dec
>> yeara year
>
> IMO dayofweek and monthofyear should use number as well. Numbers
> are easier to process.
>
On the other hand, names of days and months keep the rule more
readable,


... for English speakers ...

I agree. We can always provide readable interface in the UI or CLI but I don't
think having names as LDAP values would be good.


which I think might be better when checking for mistakes in those
rules.


In most cases people will read these rules after they have been through
a parser that can translate numbers in whatever locale names the user
uses. Using numbers is preferable.

Please let's not mix schema and presentation here. The LDAP schema
should be tilted toward coding convenience first and readability second
(with exceptions as always).

Yep.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Simo Sorce]

On Thu, 2015-04-16 at 10:04 +0200, Stanislav Láznička wrote:
> >> Possible values of each keyword:
> >> timeofday   -2359
> >> dayofweek   Mon, Tue, Wed, Thu, Fri, Sat, Sun
> >> dayofmonth  1-31
> >> weekofmonth 1-5
> >> monthofyear Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, 
> >> Nov, Dec
> >> yeara year
> >
> > IMO dayofweek and monthofyear should use number as well. Numbers
> are 
> > easier to process.
> >
> On the other hand, names of days and months keep the rule more
> readable, 

... for English speakers ...

> which I think might be better when checking for mistakes in those
> rules.

In most cases people will read these rules after they have been through
a parser that can translate numbers in whatever locale names the user
uses. Using numbers is preferable.

Please let's not mix schema and presentation here. The LDAP schema
should be tilted toward coding convenience first and readability second
(with exceptions as always).

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Standa Láznička]

On 4/16/2015 10:26 AM, Alexander Bokovoy wrote:

On Thu, 16 Apr 2015, Stanislav Láznička wrote:

On 04/16/2015 08:04 AM, Jan Cholasta wrote:

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

Hi,

I have prepared a feature proposal for the wiki. I followed the 
Feature
Proposal Template and the chapter "How to Test" is currently 
missing so
it might rather be considered a draft. Please, see it, I hope it's 
alright.


The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules.
However, handling access to a host in repeating time periods might 
be a
desirable feature. The administrator of a certain environment 
should be
able to set the time a host should be accessed in either the host 
local
time, a certain time zone time or in UTC. Host-local-time policies 
would

allow to adapt the time a host can be accessed to the host's movement
along different time zones. A time bound to a certain time zone is 
more

transparent than local time as it doesn't change with the host
traveling. Sometimes, it may also be important to set time in UTC. 
This

is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs 
to be

accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain
time zone. This access is repeated in a way, such as three times a 
week
the same time except for once a year where there's regular 
maintenance.


Design
The time based account policies are an extension to the current (April
2015) HBAC plugin. It assumes the time through the system is well 
set on

all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three
different views. These are: host local time, time at a certain time
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely
to move across different time zones and for some reason it's important
that the time they can be accessed reflects their current position. 
This

helps creating only a single HBAC rule instead of multiple when only
time zone or UTC rules would apply. The time of a host is counted 
using
the /etc/timezone information of the certain host. Testing of such 
rule

requires the tester to specify a certain time zone the rule would be
tested against.
It's important to note that this type of policy may bring some
unexpected behavior as hosts move across the globe, or even in a 
single

hostgroup, when there're hosts from multiple timezones, and
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain 
time
zone. This might be interesting when the time settings should 
reflect a
certain time zone, eg. the host or the users connecting to it are 
to be
found in that certain time zone. The time zone offset to count the 
time

of access is taken from the Olson database. Therefore, even daylight
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the 
same for

the whole globe throughout the year. That's why UTC should also be
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that 
applies

such a policy. This extension is designed so that the LDAP schema does
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC
rule object. The policy is a string in a form of tuple: (anchor, 
time).
In this tuple, the anchor is one of "host", "utc" or Olson database 
time

zone name, such as "Europe/Prague". The meaning of the anchor follows
the time scenarios from this design. The time part of the policy tuple
is the time range of the policy.


It should be called "timezone", not "anchor". Anchor was something 
different (and I really regret calling it that, seeing how it got 
stuck).


Is there any real benefit in storing time zone with each access 
time? I think it should be good enough to have one time zone per 
HBAC rule, which would also reduce complexity of the whole thing.


I was thinking "host", "utc" - these are not timezones. Maybe it 
would be more accurate to call it an anchor or a handle.

And you are wrong here.
Olson database does have UTC as a timezone designator. I said previously
that this field should have just a value of Olson database and that's
fine. Simo was also talking about using an empty string to indicate 'use
timezone of the server' and I think with this we'd get a simple logic:

- if timezone value is empty (''), timezone of the target server is 
used, based

 on /etc/localtime value.
- if timezone value is not empty, it designates a timezone from Olson
 database.

No need to invent anything else here, in my opinion.


Oh, I see. No problem calling it a timezone, then, as such description 
is accurate.


--
Manage your subscription for the Freeipa-devel mailing list:
https:

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Alexander Bokovoy]

On Thu, 16 Apr 2015, Stanislav Láznička wrote:

On 04/16/2015 08:04 AM, Jan Cholasta wrote:

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

Hi,

I have prepared a feature proposal for the wiki. I followed the Feature
Proposal Template and the chapter "How to Test" is currently missing so
it might rather be considered a draft. Please, see it, I hope it's 
alright.


The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules.
However, handling access to a host in repeating time periods might be a
desirable feature. The administrator of a certain environment should be
able to set the time a host should be accessed in either the host local
time, a certain time zone time or in UTC. Host-local-time policies would
allow to adapt the time a host can be accessed to the host's movement
along different time zones. A time bound to a certain time zone is more
transparent than local time as it doesn't change with the host
traveling. Sometimes, it may also be important to set time in UTC. This
is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs to be
accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain
time zone. This access is repeated in a way, such as three times a week
the same time except for once a year where there's regular maintenance.

Design
The time based account policies are an extension to the current (April
2015) HBAC plugin. It assumes the time through the system is well set on
all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three
different views. These are: host local time, time at a certain time
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely
to move across different time zones and for some reason it's important
that the time they can be accessed reflects their current position. This
helps creating only a single HBAC rule instead of multiple when only
time zone or UTC rules would apply. The time of a host is counted using
the /etc/timezone information of the certain host. Testing of such rule
requires the tester to specify a certain time zone the rule would be
tested against.
It's important to note that this type of policy may bring some
unexpected behavior as hosts move across the globe, or even in a single
hostgroup, when there're hosts from multiple timezones, and
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain time
zone. This might be interesting when the time settings should reflect a
certain time zone, eg. the host or the users connecting to it are to be
found in that certain time zone. The time zone offset to count the time
of access is taken from the Olson database. Therefore, even daylight
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the same for
the whole globe throughout the year. That's why UTC should also be
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that applies
such a policy. This extension is designed so that the LDAP schema does
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC
rule object. The policy is a string in a form of tuple: (anchor, time).
In this tuple, the anchor is one of "host", "utc" or Olson database time
zone name, such as "Europe/Prague". The meaning of the anchor follows
the time scenarios from this design. The time part of the policy tuple
is the time range of the policy.


It should be called "timezone", not "anchor". Anchor was something 
different (and I really regret calling it that, seeing how it got 
stuck).


Is there any real benefit in storing time zone with each access 
time? I think it should be good enough to have one time zone per 
HBAC rule, which would also reduce complexity of the whole thing.


I was thinking "host", "utc" - these are not timezones. Maybe it would 
be more accurate to call it an anchor or a handle.

And you are wrong here.
Olson database does have UTC as a timezone designator. I said previously
that this field should have just a value of Olson database and that's
fine. Simo was also talking about using an empty string to indicate 'use
timezone of the server' and I think with this we'd get a simple logic:

- if timezone value is empty (''), timezone of the target server is used, based
 on /etc/localtime value.
- if timezone value is not empty, it designates a timezone from Olson
 database.

No need to invent anything else here, in my opinion.


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Jan Cholasta]

Dne 16.4.2015 v 10:04 Stanislav Láznička napsal(a):

On 04/16/2015 08:04 AM, Jan Cholasta wrote:

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

Hi,

I have prepared a feature proposal for the wiki. I followed the Feature
Proposal Template and the chapter "How to Test" is currently missing so
it might rather be considered a draft. Please, see it, I hope it's
alright.

The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules.
However, handling access to a host in repeating time periods might be a
desirable feature. The administrator of a certain environment should be
able to set the time a host should be accessed in either the host local
time, a certain time zone time or in UTC. Host-local-time policies would
allow to adapt the time a host can be accessed to the host's movement
along different time zones. A time bound to a certain time zone is more
transparent than local time as it doesn't change with the host
traveling. Sometimes, it may also be important to set time in UTC. This
is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs to be
accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain
time zone. This access is repeated in a way, such as three times a week
the same time except for once a year where there's regular maintenance.

Design
The time based account policies are an extension to the current (April
2015) HBAC plugin. It assumes the time through the system is well set on
all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three
different views. These are: host local time, time at a certain time
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely
to move across different time zones and for some reason it's important
that the time they can be accessed reflects their current position. This
helps creating only a single HBAC rule instead of multiple when only
time zone or UTC rules would apply. The time of a host is counted using
the /etc/timezone information of the certain host. Testing of such rule
requires the tester to specify a certain time zone the rule would be
tested against.
It's important to note that this type of policy may bring some
unexpected behavior as hosts move across the globe, or even in a single
hostgroup, when there're hosts from multiple timezones, and
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain time
zone. This might be interesting when the time settings should reflect a
certain time zone, eg. the host or the users connecting to it are to be
found in that certain time zone. The time zone offset to count the time
of access is taken from the Olson database. Therefore, even daylight
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the same for
the whole globe throughout the year. That's why UTC should also be
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that applies
such a policy. This extension is designed so that the LDAP schema does
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC
rule object. The policy is a string in a form of tuple: (anchor, time).
In this tuple, the anchor is one of "host", "utc" or Olson database time
zone name, such as "Europe/Prague". The meaning of the anchor follows
the time scenarios from this design. The time part of the policy tuple
is the time range of the policy.


It should be called "timezone", not "anchor". Anchor was something
different (and I really regret calling it that, seeing how it got stuck).

Is there any real benefit in storing time zone with each access time?
I think it should be good enough to have one time zone per HBAC rule,
which would also reduce complexity of the whole thing.


I was thinking "host", "utc" - these are not timezones. Maybe it would
be more accurate to call it an anchor or a handle.


"UTC" is a timezone according to 
.


The value usually is a valid timezone, I don't think we need to call it 
differently because of *one* value which is not.




The timezone should probably be stored just once in the rule, you're
right. In the design, I was aiming for not changing the schema, but it
probably makes no sense to keep it as it is.


The language of the time half of the time policy tuple is inspired by
the time part of Bind Rules of 389 Directory Server. Aside from the Bind
Rules keywords timeofday and dayofweek, it adds keywords dayofmonth,
weekofmonth, monthofyear and year. There are three operators: assignment
("="), range ("-") and union(","). Assignment operator is used after
each of the keywords above to specif

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Stanislav Láznička]

On 04/16/2015 08:04 AM, Jan Cholasta wrote:

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

Hi,

I have prepared a feature proposal for the wiki. I followed the Feature
Proposal Template and the chapter "How to Test" is currently missing so
it might rather be considered a draft. Please, see it, I hope it's 
alright.


The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules.
However, handling access to a host in repeating time periods might be a
desirable feature. The administrator of a certain environment should be
able to set the time a host should be accessed in either the host local
time, a certain time zone time or in UTC. Host-local-time policies would
allow to adapt the time a host can be accessed to the host's movement
along different time zones. A time bound to a certain time zone is more
transparent than local time as it doesn't change with the host
traveling. Sometimes, it may also be important to set time in UTC. This
is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs to be
accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain
time zone. This access is repeated in a way, such as three times a week
the same time except for once a year where there's regular maintenance.

Design
The time based account policies are an extension to the current (April
2015) HBAC plugin. It assumes the time through the system is well set on
all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three
different views. These are: host local time, time at a certain time
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely
to move across different time zones and for some reason it's important
that the time they can be accessed reflects their current position. This
helps creating only a single HBAC rule instead of multiple when only
time zone or UTC rules would apply. The time of a host is counted using
the /etc/timezone information of the certain host. Testing of such rule
requires the tester to specify a certain time zone the rule would be
tested against.
It's important to note that this type of policy may bring some
unexpected behavior as hosts move across the globe, or even in a single
hostgroup, when there're hosts from multiple timezones, and
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain time
zone. This might be interesting when the time settings should reflect a
certain time zone, eg. the host or the users connecting to it are to be
found in that certain time zone. The time zone offset to count the time
of access is taken from the Olson database. Therefore, even daylight
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the same for
the whole globe throughout the year. That's why UTC should also be
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that applies
such a policy. This extension is designed so that the LDAP schema does
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC
rule object. The policy is a string in a form of tuple: (anchor, time).
In this tuple, the anchor is one of "host", "utc" or Olson database time
zone name, such as "Europe/Prague". The meaning of the anchor follows
the time scenarios from this design. The time part of the policy tuple
is the time range of the policy.


It should be called "timezone", not "anchor". Anchor was something 
different (and I really regret calling it that, seeing how it got stuck).


Is there any real benefit in storing time zone with each access time? 
I think it should be good enough to have one time zone per HBAC rule, 
which would also reduce complexity of the whole thing.


I was thinking "host", "utc" - these are not timezones. Maybe it would 
be more accurate to call it an anchor or a handle.


The timezone should probably be stored just once in the rule, you're 
right. In the design, I was aiming for not changing the schema, but it 
probably makes no sense to keep it as it is.


The language of the time half of the time policy tuple is inspired by
the time part of Bind Rules of 389 Directory Server. Aside from the Bind
Rules keywords timeofday and dayofweek, it adds keywords dayofmonth,
weekofmonth, monthofyear and year. There are three operators: assignment
("="), range ("-") and union(","). Assignment operator is used after
each of the keywords above to specify the value of the certain keyword.
Range operator may be used for setting ranges of hours, days, months
etc. The final range includes both boundaries of the range set. A union
operator is used when the keyword should contain a union of values
rather than a range. Also

Re: [Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Jan Cholasta]

Hi,

Dne 15.4.2015 v 16:07 Stanislav Láznička napsal(a):

Hi,

I have prepared a feature proposal for the wiki. I followed the Feature
Proposal Template and the chapter "How to Test" is currently missing so
it might rather be considered a draft. Please, see it, I hope it's alright.

The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules.
However, handling access to a host in repeating time periods might be a
desirable feature. The administrator of a certain environment should be
able to set the time a host should be accessed in either the host local
time, a certain time zone time or in UTC. Host-local-time policies would
allow to adapt the time a host can be accessed to the host's movement
along different time zones. A time bound to a certain time zone is more
transparent than local time as it doesn't change with the host
traveling. Sometimes, it may also be important to set time in UTC. This
is rather strict setting that does not reflect daylight saving time.

Use Cases
1. A host is changing position on the globe quite often and needs to be
accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain
time zone. This access is repeated in a way, such as three times a week
the same time except for once a year where there's regular maintenance.

Design
The time based account policies are an extension to the current (April
2015) HBAC plugin. It assumes the time through the system is well set on
all host stations via the NTP.

Time Scenarios
This extension is designed so that it understands time in three
different views. These are: host local time, time at a certain time
zone, and UTC.

Host Local Time
Host local time approach is meant for those hosts that are most likely
to move across different time zones and for some reason it's important
that the time they can be accessed reflects their current position. This
helps creating only a single HBAC rule instead of multiple when only
time zone or UTC rules would apply. The time of a host is counted using
the /etc/timezone information of the certain host. Testing of such rule
requires the tester to specify a certain time zone the rule would be
tested against.
It's important to note that this type of policy may bring some
unexpected behavior as hosts move across the globe, or even in a single
hostgroup, when there're hosts from multiple timezones, and
administrator should be very sure they want to use this.

Time Zones
In this approach, the time is thought of as of a time at a certain time
zone. This might be interesting when the time settings should reflect a
certain time zone, eg. the host or the users connecting to it are to be
found in that certain time zone. The time zone offset to count the time
of access is taken from the Olson database. Therefore, even daylight
saving time is taken into account.

UTC
Sometimes the rules should apply for a certain time that is the same for
the whole globe throughout the year. That's why UTC should also be
supported.

Time Policies Storage
The time policies should be stored with each the HBAC rule that applies
such a policy. This extension is designed so that the LDAP schema does
not have to be changed.

The time policies are stored in the accessTime attribute of the HBAC
rule object. The policy is a string in a form of tuple: (anchor, time).
In this tuple, the anchor is one of "host", "utc" or Olson database time
zone name, such as "Europe/Prague". The meaning of the anchor follows
the time scenarios from this design. The time part of the policy tuple
is the time range of the policy.


It should be called "timezone", not "anchor". Anchor was something 
different (and I really regret calling it that, seeing how it got stuck).


Is there any real benefit in storing time zone with each access time? I 
think it should be good enough to have one time zone per HBAC rule, 
which would also reduce complexity of the whole thing.




The language of the time half of the time policy tuple is inspired by
the time part of Bind Rules of 389 Directory Server. Aside from the Bind
Rules keywords timeofday and dayofweek, it adds keywords dayofmonth,
weekofmonth, monthofyear and year. There are three operators: assignment
("="), range ("-") and union(","). Assignment operator is used after
each of the keywords above to specify the value of the certain keyword.
Range operator may be used for setting ranges of hours, days, months
etc. The final range includes both boundaries of the range set. A union
operator is used when the keyword should contain a union of values
rather than a range. Also, it can be used to make a union of ranges.

Possible values of each keyword:
timeofday   -2359
dayofweek   Mon, Tue, Wed, Thu, Fri, Sat, Sun
dayofmonth  1-31
weekofmonth 1-5
monthofyear Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
yeara year


IMO dayofweek and monthofyear should use number as well. Numbers

[Freeipa-devel] Time-Based Account Policies - Feature Proposal

[Stanislav Láznička]

Hi,

I have prepared a feature proposal for the wiki. I followed the Feature 
Proposal Template and the chapter "How to Test" is currently missing so 
it might rather be considered a draft. Please, see it, I hope it's alright.


The text:

Overview
FreeIPA is currently missing any temporal settings in the HBAC rules. 
However, handling access to a host in repeating time periods might be a 
desirable feature. The administrator of a certain environment should be 
able to set the time a host should be accessed in either the host local 
time, a certain time zone time or in UTC. Host-local-time policies would 
allow to adapt the time a host can be accessed to the host's movement 
along different time zones. A time bound to a certain time zone is more 
transparent than local time as it doesn't change with the host 
traveling. Sometimes, it may also be important to set time in UTC. This 
is rather strict setting that does not reflect daylight saving time.


Use Cases
1. A host is changing position on the globe quite often and needs to be 
accessed at certain times reflecting its current time zone.
2. A host should only be accessed at certain times given by a certain 
time zone. This access is repeated in a way, such as three times a week 
the same time except for once a year where there's regular maintenance.


Design
The time based account policies are an extension to the current (April 
2015) HBAC plugin. It assumes the time through the system is well set on 
all host stations via the NTP.


Time Scenarios
This extension is designed so that it understands time in three 
different views. These are: host local time, time at a certain time 
zone, and UTC.


Host Local Time
Host local time approach is meant for those hosts that are most likely 
to move across different time zones and for some reason it's important 
that the time they can be accessed reflects their current position. This 
helps creating only a single HBAC rule instead of multiple when only 
time zone or UTC rules would apply. The time of a host is counted using 
the /etc/timezone information of the certain host. Testing of such rule 
requires the tester to specify a certain time zone the rule would be 
tested against.
It's important to note that this type of policy may bring some 
unexpected behavior as hosts move across the globe, or even in a single 
hostgroup, when there're hosts from multiple timezones, and 
administrator should be very sure they want to use this.


Time Zones
In this approach, the time is thought of as of a time at a certain time 
zone. This might be interesting when the time settings should reflect a 
certain time zone, eg. the host or the users connecting to it are to be 
found in that certain time zone. The time zone offset to count the time 
of access is taken from the Olson database. Therefore, even daylight 
saving time is taken into account.


UTC
Sometimes the rules should apply for a certain time that is the same for 
the whole globe throughout the year. That's why UTC should also be 
supported.


Time Policies Storage
The time policies should be stored with each the HBAC rule that applies 
such a policy. This extension is designed so that the LDAP schema does 
not have to be changed.


The time policies are stored in the accessTime attribute of the HBAC 
rule object. The policy is a string in a form of tuple: (anchor, time). 
In this tuple, the anchor is one of "host", "utc" or Olson database time 
zone name, such as "Europe/Prague". The meaning of the anchor follows 
the time scenarios from this design. The time part of the policy tuple 
is the time range of the policy.


The language of the time half of the time policy tuple is inspired by 
the time part of Bind Rules of 389 Directory Server. Aside from the Bind 
Rules keywords timeofday and dayofweek, it adds keywords dayofmonth, 
weekofmonth, monthofyear and year. There are three operators: assignment 
("="), range ("-") and union(","). Assignment operator is used after 
each of the keywords above to specify the value of the certain keyword. 
Range operator may be used for setting ranges of hours, days, months 
etc. The final range includes both boundaries of the range set. A union 
operator is used when the keyword should contain a union of values 
rather than a range. Also, it can be used to make a union of ranges.


Possible values of each keyword:
timeofday   -2359
dayofweek   Mon, Tue, Wed, Thu, Fri, Sat, Sun
dayofmonth  1-31
weekofmonth 1-5
monthofyear Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec
yeara year

Example:
(host, timeofday="0800-1200, 1230-1600" dayofweek="Mon-Thu, Sat")

Similarly to Bind Rules, it is possible to write an time policy as a 
longer expression using the "and" and "or" logical operators. In this 
case, each of separate block of the policy should appear in parentheses. 
It is also possible to add time exceptions for the policy. That's 
performed using the except() block that should ap

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/26/2015 05:06 PM, Simo Sorce wrote:
> On Thu, 2015-03-26 at 16:47 +0100, Martin Kosek wrote:
...
>> Reference:
>> http://www.redhat.com/archives/freeipa-devel/2015-March/msg00158.html
> 
> I see how the language I sued may be confusing. But I was pointing out
> only that you can't just do one or the other you have to support all
> these cases, I wasn't advocating using UTC as the "timezoned" option.
> 
> If I should choose I would support all three flavors:
> - the special "Local Time" string
> - the Olson database (Europe/Rome)
> - absolute UTC offsets (UTC+4)

Yup, makes sense.

> However I would not publicize the latter much in the UI, as it is rarely
> what the admin really should do.



-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

On Thu, 2015-03-26 at 16:47 +0100, Martin Kosek wrote:
> On 03/26/2015 04:39 PM, Simo Sorce wrote:
> > On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:
> >> On 03/26/2015 04:26 PM, Jan Cholasta wrote:
> > 
> > [...]
> >>> I don't see any point in storing time zone in the host object, if it's 
> >>> not used
> >>> for anything meaningful and has to be manually synchronized with the 
> >>> host's
> >>> actual configured time zone.
> >>
> >> It would be mostly used for aiding the HBAC rule creation process, i.e. 
> >> for the
> >> UX. It would be optional. If you do not fill it, you would have to always
> >> select the right time zone in when setting the UTC HBAC time,
> >>
> >> If you fill the zone, UI could already select the right time zone for you.
> > 
> > 
> > It will only help to do mistakes, how does the host object get to know
> > what is the host's timezone ? And in any case you generally create HBAC
> > rules using groups of hosts, what is the UI gonna do ? Crawl all the
> > hosts in a group and then ? Average add the most common time zone ?
> 
> Search hosts, gather all time zones and list them as choices or simply warn
> that there are more time zones and Local Time based rule is preferred? :-)
> 
> > Drop it please :)
> 
> If there is no one interested in it, we can drop it. Such UX improvement can
> also be added later, if there is a need.
> 
> > 
> >> Host's Local Time and UTC time are 2 different approaches how to set the 
> >> time
> >> for the HBAC rule. With Local Time type, you would of course not have to 
> >> deal
> >> with time zones. I thought this was already cleared out.
> > 
> > Sorry you confuse me, in which case do you need UTC ?
> > In case you want to set an absolute time  that doesn't change with DST ?
> 
> I am confused as well. Wasn't it you who expressed the need to have 2 
> different
> approaches for HBAC time rules - Local Time and fixed UTC time?

Not really, Olson is correct.

> Reference:
> http://www.redhat.com/archives/freeipa-devel/2015-March/msg00158.html

I see how the language I sued may be confusing. But I was pointing out
only that you can't just do one or the other you have to support all
these cases, I wasn't advocating using UTC as the "timezoned" option.

If I should choose I would support all three flavors:
- the special "Local Time" string
- the Olson database (Europe/Rome)
- absolute UTC offsets (UTC+4)

However I would not publicize the latter much in the UI, as it is rarely
what the admin really should do.

Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/26/2015 04:57 PM, Jan Cholasta wrote:
> Dne 26.3.2015 v 16:47 Martin Kosek napsal(a):
>> On 03/26/2015 04:39 PM, Simo Sorce wrote:
>>> On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:
 On 03/26/2015 04:26 PM, Jan Cholasta wrote:
>>>
>>> [...]
> I don't see any point in storing time zone in the host object, if it's not
> used
> for anything meaningful and has to be manually synchronized with the 
> host's
> actual configured time zone.

 It would be mostly used for aiding the HBAC rule creation process, i.e. for
 the
 UX. It would be optional. If you do not fill it, you would have to always
 select the right time zone in when setting the UTC HBAC time,

 If you fill the zone, UI could already select the right time zone for you.
>>>
>>>
>>> It will only help to do mistakes, how does the host object get to know
>>> what is the host's timezone ? And in any case you generally create HBAC
>>> rules using groups of hosts, what is the UI gonna do ? Crawl all the
>>> hosts in a group and then ? Average add the most common time zone ?
>>
>> Search hosts, gather all time zones and list them as choices or simply warn
>> that there are more time zones and Local Time based rule is preferred? :-)
>>
>>> Drop it please :)
>>
>> If there is no one interested in it, we can drop it. Such UX improvement can
>> also be added later, if there is a need.
> 
> If we want to improve the UX by babysitting the administrator based on random
> guesses, we might as well add Clippy to IPA:
> 
>  __
> /  \_
> |  |   / \
> @  @   | It looks|
> || ||  | like you|
> || ||   <--| are setting |
> |\_/|  | time zone   |
> \___/  \_/
> 
> 
> ;-)
> 

:-D

I see your point. Just note that what seems as neeedless babysitting from your
(or other) POV may be a very useful UX for the real world user. But in this
case we can wait until we hear from that real world user that he struggles with
the potential time based rules UI.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Jan Cholasta]

Dne 26.3.2015 v 16:47 Martin Kosek napsal(a):

On 03/26/2015 04:39 PM, Simo Sorce wrote:

On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:

On 03/26/2015 04:26 PM, Jan Cholasta wrote:


[...]

I don't see any point in storing time zone in the host object, if it's not used
for anything meaningful and has to be manually synchronized with the host's
actual configured time zone.


It would be mostly used for aiding the HBAC rule creation process, i.e. for the
UX. It would be optional. If you do not fill it, you would have to always
select the right time zone in when setting the UTC HBAC time,

If you fill the zone, UI could already select the right time zone for you.



It will only help to do mistakes, how does the host object get to know
what is the host's timezone ? And in any case you generally create HBAC
rules using groups of hosts, what is the UI gonna do ? Crawl all the
hosts in a group and then ? Average add the most common time zone ?


Search hosts, gather all time zones and list them as choices or simply warn
that there are more time zones and Local Time based rule is preferred? :-)


Drop it please :)


If there is no one interested in it, we can drop it. Such UX improvement can
also be added later, if there is a need.


If we want to improve the UX by babysitting the administrator based on 
random guesses, we might as well add Clippy to IPA:


 __
/  \_
|  |   / \
@  @   | It looks|
|| ||  | like you|
|| ||   <--| are setting |
|\_/|  | time zone   |
\___/  \_/


;-)

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/26/2015 04:42 PM, Simo Sorce wrote:
> On Thu, 2015-03-26 at 16:39 +0100, Martin Kosek wrote:
>> On 03/26/2015 04:30 PM, Simo Sorce wrote:
>>> On Thu, 2015-03-26 at 16:26 +0100, Jan Cholasta wrote:
>> 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.

 I don't see any point in storing time zone in the host object, if
 it's 
 not used for anything meaningful and has to be manually synchronized 
 with the host's actual configured time zone.
>>>
>>> +1
>>> The host *knows* it's local time zone, let's not set us up for sync
>>> issues.
>>>
>
> 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  [ ]

 No, thanks. The whole point of "Local Time" is being able to use 
 whatever time zone is configured on each host instead of having to 
 specify one time zone for all of them, which is exactly what the above
 does.
>>>
>>> +1
>>> "Local Time" is a special name the stray out of the Olson database, you
>>> can see it as the wildcard '*' or 'ALL' in other rules and it means that
>>> the host will use its local time zone with the specified times of day
>>> and days of the week
>>
>> See http://www.redhat.com/archives/freeipa-devel/2015-March/msg00447.html.
>>
>> I agree with you both if we are talking about Local Time rules. I was mostly
>> talking about UTC rules where the time zone is required to set the right UTC 
>> time.
> 
> Sorry, but if I understand what you are suggesting then I do not agree.
> Either you use UTC based timezones *or* you use an Olson time zone. You
> do *not* try to convert something like Europe/Prague to UTC as you would
> change the meaning of the rule.

Ah, I think where the confusion is coming from. When I said UTC, I rather meant
time + Olson TZ, i.e. time rule that is the same across globe, unlike the Local
Time. Sorry.

I think this guy
(http://www.redhat.com/archives/freeipa-devel/2015-March/msg00158.html)
injected the "UTC" as an alias for this method :-)

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/26/2015 04:39 PM, Simo Sorce wrote:
> On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:
>> On 03/26/2015 04:26 PM, Jan Cholasta wrote:
> 
> [...]
>>> I don't see any point in storing time zone in the host object, if it's not 
>>> used
>>> for anything meaningful and has to be manually synchronized with the host's
>>> actual configured time zone.
>>
>> It would be mostly used for aiding the HBAC rule creation process, i.e. for 
>> the
>> UX. It would be optional. If you do not fill it, you would have to always
>> select the right time zone in when setting the UTC HBAC time,
>>
>> If you fill the zone, UI could already select the right time zone for you.
> 
> 
> It will only help to do mistakes, how does the host object get to know
> what is the host's timezone ? And in any case you generally create HBAC
> rules using groups of hosts, what is the UI gonna do ? Crawl all the
> hosts in a group and then ? Average add the most common time zone ?

Search hosts, gather all time zones and list them as choices or simply warn
that there are more time zones and Local Time based rule is preferred? :-)

> Drop it please :)

If there is no one interested in it, we can drop it. Such UX improvement can
also be added later, if there is a need.

> 
>> Host's Local Time and UTC time are 2 different approaches how to set the time
>> for the HBAC rule. With Local Time type, you would of course not have to deal
>> with time zones. I thought this was already cleared out.
> 
> Sorry you confuse me, in which case do you need UTC ?
> In case you want to set an absolute time  that doesn't change with DST ?

I am confused as well. Wasn't it you who expressed the need to have 2 different
approaches for HBAC time rules - Local Time and fixed UTC time?

Reference:
http://www.redhat.com/archives/freeipa-devel/2015-March/msg00158.html

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

On Thu, 2015-03-26 at 16:39 +0100, Martin Kosek wrote:
> On 03/26/2015 04:30 PM, Simo Sorce wrote:
> > On Thu, 2015-03-26 at 16:26 +0100, Jan Cholasta wrote:
>  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.
> >>
> >> I don't see any point in storing time zone in the host object, if
> >> it's 
> >> not used for anything meaningful and has to be manually synchronized 
> >> with the host's actual configured time zone.
> > 
> > +1
> > The host *knows* it's local time zone, let's not set us up for sync
> > issues.
> > 
> >>>
> >>> 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  [ ]
> >>
> >> No, thanks. The whole point of "Local Time" is being able to use 
> >> whatever time zone is configured on each host instead of having to 
> >> specify one time zone for all of them, which is exactly what the above
> >> does.
> > 
> > +1
> > "Local Time" is a special name the stray out of the Olson database, you
> > can see it as the wildcard '*' or 'ALL' in other rules and it means that
> > the host will use its local time zone with the specified times of day
> > and days of the week
> 
> See http://www.redhat.com/archives/freeipa-devel/2015-March/msg00447.html.
> 
> I agree with you both if we are talking about Local Time rules. I was mostly
> talking about UTC rules where the time zone is required to set the right UTC 
> time.

Sorry, but if I understand what you are suggesting then I do not agree.
Either you use UTC based timezones *or* you use an Olson time zone. You
do *not* try to convert something like Europe/Prague to UTC as you would
change the meaning of the rule.

Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/26/2015 04:30 PM, Simo Sorce wrote:
> On Thu, 2015-03-26 at 16:26 +0100, Jan Cholasta wrote:
 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.
>>
>> I don't see any point in storing time zone in the host object, if
>> it's 
>> not used for anything meaningful and has to be manually synchronized 
>> with the host's actual configured time zone.
> 
> +1
> The host *knows* it's local time zone, let's not set us up for sync
> issues.
> 
>>>
>>> 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  [ ]
>>
>> No, thanks. The whole point of "Local Time" is being able to use 
>> whatever time zone is configured on each host instead of having to 
>> specify one time zone for all of them, which is exactly what the above
>> does.
> 
> +1
> "Local Time" is a special name the stray out of the Olson database, you
> can see it as the wildcard '*' or 'ALL' in other rules and it means that
> the host will use its local time zone with the specified times of day
> and days of the week

See http://www.redhat.com/archives/freeipa-devel/2015-March/msg00447.html.

I agree with you both if we are talking about Local Time rules. I was mostly
talking about UTC rules where the time zone is required to set the right UTC 
time.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

On Thu, 2015-03-26 at 16:35 +0100, Martin Kosek wrote:
> On 03/26/2015 04:26 PM, Jan Cholasta wrote:

[...]
> > I don't see any point in storing time zone in the host object, if it's not 
> > used
> > for anything meaningful and has to be manually synchronized with the host's
> > actual configured time zone.
> 
> It would be mostly used for aiding the HBAC rule creation process, i.e. for 
> the
> UX. It would be optional. If you do not fill it, you would have to always
> select the right time zone in when setting the UTC HBAC time,
> 
> If you fill the zone, UI could already select the right time zone for you.


It will only help to do mistakes, how does the host object get to know
what is the host's timezone ? And in any case you generally create HBAC
rules using groups of hosts, what is the UI gonna do ? Crawl all the
hosts in a group and then ? Average add the most common time zone ?

Drop it please :)

> Host's Local Time and UTC time are 2 different approaches how to set the time
> for the HBAC rule. With Local Time type, you would of course not have to deal
> with time zones. I thought this was already cleared out.

Sorry you confuse me, in which case do you need UTC ?
In case you want to set an absolute time  that doesn't change with DST ?


Simo.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/26/2015 04:26 PM, Jan Cholasta wrote:
> Dne 26.3.2015 v 14:55 Martin Kosek napsal(a):
>> 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.
> 
> Ah, right. OK then.
> 
 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.
> 
> I don't see any point in storing time zone in the host object, if it's not 
> used
> for anything meaningful and has to be manually synchronized with the host's
> actual configured time zone.

It would be mostly used for aiding the HBAC rule creation process, i.e. for the
UX. It would be optional. If you do not fill it, you would have to always
select the right time zone in when setting the UTC HBAC time,

If you fill the zone, UI could already select the right time zone for you.

>> 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  [ ]
> 
> No, thanks. The whole point of "Local Time" is being able to use whatever time
> zone is configured on each host instead of having to specify one time zone for
> all of them, which is exactly what the above does.

Host's Local Time and UTC time are 2 different approaches how to set the time
for the HBAC rule. With Local Time type, you would of course not have to deal
with time zones. I thought this was already cleared out.

>>> 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
>

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

On Thu, 2015-03-26 at 16:26 +0100, Jan Cholasta wrote:
> >> 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.
> 
> I don't see any point in storing time zone in the host object, if
> it's 
> not used for anything meaningful and has to be manually synchronized 
> with the host's actual configured time zone.

+1
The host *knows* it's local time zone, let's not set us up for sync
issues.

> >
> > 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  [ ]
> 
> No, thanks. The whole point of "Local Time" is being able to use 
> whatever time zone is configured on each host instead of having to 
> specify one time zone for all of them, which is exactly what the above
> does.

+1
"Local Time" is a special name the stray out of the Olson database, you
can see it as the wildcard '*' or 'ALL' in other rules and it means that
the host will use its local time zone with the specified times of day
and days of the week

Simo.


-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Jan Cholasta]

Dne 26.3.2015 v 14:55 Martin Kosek napsal(a):

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.


Ah, right. OK then.


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.


I don't see any point in storing time zone in the host object, if it's 
not used for anything meaningful and has to be manually synchronized 
with the host's actual configured time zone.




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  [ ]


No, thanks. The whole point of "Local Time" is being able to use 
whatever time zone is configured on each host instead of having to 
specify one time zone for all of them, which is exactly what the above does.





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).




Can we please stop using the word "anchor" for time zone, rather than 
source of time zone information as I originally suggested?


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Standa Láznička]

> On 26. 3. 2015, at 14:55, Martin Kosek  wrote:
> 
>> 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 see. An option to choose a different time zone than the hosts' might also 
come handy here but I see where you're going.
> 
>> 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).
> 

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [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).

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Standa Láznička]

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.


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).


--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

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.

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)

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Standa Láznička]

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.


That leaves us with 2 kinds of policies - UTC and Local Time (which is
enforced by hosts' /etc/localtime). Now with the (time, anchor) format
for time policies, the LDAP schema wouldn't have to change and we could
just use the AccessTime attribute of the HBAC Rule object that's already
there. That seems like a good solution to me.

I hope we can agree on the above although any notes are, of course,
welcome. Now we would need to choose the right format for the time part
of (time, anchor) I guess. There's been a discussion some 2 weeks ago
about the need for event recurrence support in the format, the need for
exceptions support and the need for iCalendar import possibility. So
far, there are three possible languages to choose from - use the actual
iCalendar or just a part of it, use a reworked version of the old
language used in FreeIPA and SSSD, or use the language I proposed
earlier in this thread.

I would be very keen on hearing your ideas and opinions on this one.

Thanks!
Standa





--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Jan Cholasta]

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".




That leaves us with 2 kinds of policies - UTC and Local Time (which is
enforced by hosts' /etc/localtime). Now with the (time, anchor) format
for time policies, the LDAP schema wouldn't have to change and we could
just use the AccessTime attribute of the HBAC Rule object that's already
there. That seems like a good solution to me.

I hope we can agree on the above although any notes are, of course,
welcome. Now we would need to choose the right format for the time part
of (time, anchor) I guess. There's been a discussion some 2 weeks ago
about the need for event recurrence support in the format, the need for
exceptions support and the need for iCalendar import possibility. So
far, there are three possible languages to choose from - use the actual
iCalendar or just a part of it, use a reworked version of the old
language used in FreeIPA and SSSD, or use the language I proposed
earlier in this thread.

I would be very keen on hearing your ideas and opinions on this one.

Thanks!
Standa



--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [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

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Stanislav Láznička]

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.


That leaves us with 2 kinds of policies - UTC and Local Time (which is 
enforced by hosts' /etc/localtime). Now with the (time, anchor) format 
for time policies, the LDAP schema wouldn't have to change and we could 
just use the AccessTime attribute of the HBAC Rule object that's already 
there. That seems like a good solution to me.


I hope we can agree on the above although any notes are, of course, 
welcome. Now we would need to choose the right format for the time part 
of (time, anchor) I guess. There's been a discussion some 2 weeks ago 
about the need for event recurrence support in the format, the need for 
exceptions support and the need for iCalendar import possibility. So 
far, there are three possible languages to choose from - use the actual 
iCalendar or just a part of it, use a reworked version of the old 
language used in FreeIPA and SSSD, or use the language I proposed 
earlier in this thread.


I would be very keen on hearing your ideas and opinions on this one.

Thanks!
Standa

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [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 woul

Re: [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 hostgroup

Re: [Freeipa-devel] Time-based account policies

[Stanislav Láznička]

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 sol

Re: [Freeipa-devel] Time-based account policies

[Jan Cholasta]

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.


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

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*.

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

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

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [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.


--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Jan Cholasta]

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.


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

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...

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Petr Spacek]

On 24.3.2015 08:20, 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.

Nitpick:
It would be nice to clearly state in docs what 'timezone' are you going to
use. Users can specify their own timezone via TZ environment variable and this
can be very different from timezone defined by /etc/localtime.

-- 
Petr^2 Spacek

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Jakub Hrozek]

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.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

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.

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.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 24 Mar 2015, Jan Cholasta wrote:

Dne 23.3.2015 v 20:17 Standa Láznička napsal(a):

On 3/23/2015 10:10 AM, Jan Cholasta wrote:

Hi,

Dne 20.3.2015 v 13:30 Stanislav Láznička napsal(a):

...

As for the local time - timezone in the tuple (time, timezone) would
only say "Local Time", which can't be found in Olson's and it means the
time record from the tuple should be compared to the client's time
settings (/etc/localtime ?).


Let me just do a braindump here:

I would think timezone, or rather location (timezone + holidays)
should be stored with user objects (but not in group objects, as users
can be members of multiple groups, which could cause conflicts). When
a user goes on a bussiness trip etc., an administrator/manager would
need to change their location accordingly to reflect that.

For hosts, timezone information is already available on the host
(/etc/localtime). I'm not sure if there is a 1-1 mapping between
timezone and holidays, but if there is not, we probably need to store
location with host objects as well. If we do that, maybe we can make
SSSD update local timezone on the host using the information stored
with the host object to allow roaming (think user laptops).


I'm not sure about storing the holiday information with any objects.
Holidays are a good example for exceptions in time rules but I'm not
sure that this information should be really stored with each user/host.
There might be cases where you want the holidays to apply and then
sometimes you may not want them to apply. Storing time exceptions with
the specific HBAC rules would solve that, I think.


I'm not saying we should store them directly with any object, but 
rather store a reference to an object defining them, so that you don't 
have to define them over and over again when you need to use them in 
multiple places.

Yes. Note also that timezone information and holiday information are
independent of each other. There are multiple holiday calendars and they
change every year. Maintaining holiday calendars can be seen as a
separate task and it is not really related to a specific timezone. A
group of timezones may share the same holiday calendar.

In general, holiday calendars aren't standardized and there are no
opensource project which provide up to date information about state
holidays for all states.




It might be a good idea to store optional owner information with
hosts, so that when the owner moves to a different location, the host
is assumed to be at that location as well (again think user laptops).

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.


Yes, timezone would need to be stored with the user, and someone or 
something (not the user, so they can't cheat) would need to change it 
when the user moves.




What would then be left to decide is whether to use the iCalendar time
format as internal, or use some other own created format. Such a format
should not only be suitable for reoccurring events, but should also be
able to handle exceptions in those events, such as holidays. It should
also be easy to import iCalendar events to this format to support events
from other sources.
...



Honza



--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Jan Cholasta]

Dne 23.3.2015 v 20:17 Standa Láznička napsal(a):

On 3/23/2015 10:10 AM, Jan Cholasta wrote:

Hi,

Dne 20.3.2015 v 13:30 Stanislav Láznička napsal(a):

...

As for the local time - timezone in the tuple (time, timezone) would
only say "Local Time", which can't be found in Olson's and it means the
time record from the tuple should be compared to the client's time
settings (/etc/localtime ?).


Let me just do a braindump here:

I would think timezone, or rather location (timezone + holidays)
should be stored with user objects (but not in group objects, as users
can be members of multiple groups, which could cause conflicts). When
a user goes on a bussiness trip etc., an administrator/manager would
need to change their location accordingly to reflect that.

For hosts, timezone information is already available on the host
(/etc/localtime). I'm not sure if there is a 1-1 mapping between
timezone and holidays, but if there is not, we probably need to store
location with host objects as well. If we do that, maybe we can make
SSSD update local timezone on the host using the information stored
with the host object to allow roaming (think user laptops).


I'm not sure about storing the holiday information with any objects.
Holidays are a good example for exceptions in time rules but I'm not
sure that this information should be really stored with each user/host.
There might be cases where you want the holidays to apply and then
sometimes you may not want them to apply. Storing time exceptions with
the specific HBAC rules would solve that, I think.


I'm not saying we should store them directly with any object, but rather 
store a reference to an object defining them, so that you don't have to 
define them over and over again when you need to use them in multiple 
places.



It might be a good idea to store optional owner information with
hosts, so that when the owner moves to a different location, the host
is assumed to be at that location as well (again think user laptops).

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.


Yes, timezone would need to be stored with the user, and someone or 
something (not the user, so they can't cheat) would need to change it 
when the user moves.




What would then be left to decide is whether to use the iCalendar time
format as internal, or use some other own created format. Such a format
should not only be suitable for reoccurring events, but should also be
able to handle exceptions in those events, such as holidays. It should
also be easy to import iCalendar events to this format to support events
from other sources.
...



Honza



--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Standa Láznička]

On 3/23/2015 10:10 AM, Jan Cholasta wrote:

Hi,

Dne 20.3.2015 v 13:30 Stanislav Láznička napsal(a):

...

As for the local time - timezone in the tuple (time, timezone) would
only say "Local Time", which can't be found in Olson's and it means the
time record from the tuple should be compared to the client's time
settings (/etc/localtime ?).


Let me just do a braindump here:

I would think timezone, or rather location (timezone + holidays) 
should be stored with user objects (but not in group objects, as users 
can be members of multiple groups, which could cause conflicts). When 
a user goes on a bussiness trip etc., an administrator/manager would 
need to change their location accordingly to reflect that.


For hosts, timezone information is already available on the host 
(/etc/localtime). I'm not sure if there is a 1-1 mapping between 
timezone and holidays, but if there is not, we probably need to store 
location with host objects as well. If we do that, maybe we can make 
SSSD update local timezone on the host using the information stored 
with the host object to allow roaming (think user laptops).


I'm not sure about storing the holiday information with any objects. 
Holidays are a good example for exceptions in time rules but I'm not 
sure that this information should be really stored with each user/host. 
There might be cases where you want the holidays to apply and then 
sometimes you may not want them to apply. Storing time exceptions with 
the specific HBAC rules would solve that, I think.
It might be a good idea to store optional owner information with 
hosts, so that when the owner moves to a different location, the host 
is assumed to be at that location as well (again think user laptops).


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.


What would then be left to decide is whether to use the iCalendar time
format as internal, or use some other own created format. Such a format
should not only be suitable for reoccurring events, but should also be
able to handle exceptions in those events, such as holidays. It should
also be easy to import iCalendar events to this format to support events
from other sources.
...



Honza

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Jan Cholasta]

Hi,

Dne 20.3.2015 v 13:30 Stanislav Láznička napsal(a):

Hi!

I went through the last week's thread on Time-Based Policies, discussed
some parts I wasn't very sure about with Martin, and would like to make
a summary of it, followed by some further questions on the topic. The
mail is a bit longer than I thought it would be. Sorry about that. It
seems I am very bad at fast and brief responses.

So to summarize - the best way to go seems to be to implement both UTC
and client-side local time support. A very nice idea is to store it in
the format (time, timezone).  Now if I understand this right, the
timezone here would be the Olson database timezone stored with the
host/hostgroup, possibly overridden by service/servicegroup timezone. It
would help the administrator decide the correct UTC time by adjusting
the time displayed in UI/CLI. The administrator should also be able to
set this timezone in the UI/CLI settings of the HBAC rule (or maybe they
just set it instead of storing timezone info with host/hostgroup etc.
objects?).

As for the local time - timezone in the tuple (time, timezone) would
only say "Local Time", which can't be found in Olson's and it means the
time record from the tuple should be compared to the client's time
settings (/etc/localtime ?).


Let me just do a braindump here:

I would think timezone, or rather location (timezone + holidays) should 
be stored with user objects (but not in group objects, as users can be 
members of multiple groups, which could cause conflicts). When a user 
goes on a bussiness trip etc., an administrator/manager would need to 
change their location accordingly to reflect that.


For hosts, timezone information is already available on the host 
(/etc/localtime). I'm not sure if there is a 1-1 mapping between 
timezone and holidays, but if there is not, we probably need to store 
location with host objects as well. If we do that, maybe we can make 
SSSD update local timezone on the host using the information stored with 
the host object to allow roaming (think user laptops).


It might be a good idea to store optional owner information with hosts, 
so that when the owner moves to a different location, the host is 
assumed to be at that location as well (again think user laptops).


Given the above, HBAC rules could contain (time, anchor), where anchor 
is "UTC", "user local time" or "host local time".




What would then be left to decide is whether to use the iCalendar time
format as internal, or use some other own created format. Such a format
should not only be suitable for reoccurring events, but should also be
able to handle exceptions in those events, such as holidays. It should
also be easy to import iCalendar events to this format to support events
from other sources.

The iCalendar format is rather heavy and if we wanted to use it as a
whole, it may be necessary to include third party libraries in the SSSD
project along with their possible vulnerabilities. There is a
possibility of using only part of the iCalendar format that handles
reoccurring events and exceptions. Example from Alexander to be found
here:
https://github.com/libical/libical/blob/master/src/test/icalrecur_test.c. That
may or may not work perfectly well, given the libical library is a
complex thing and we'd be taking just a part of it.

The other time format option is to simplify/edit the language that was
used in the past (described with regular expressions here:
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=1ce240367a2144500187ccd3c0d32c975d8d346a).
There was probably a reason to step out of the language (the possibility
of parsing those iCalendar events, I guess) and it may or may not be
possible to fix the language so that the problems with it are dealt with.

I was also inspired by the language of the time part of Bind Rules from
389 Directory Server and created a possible language that might be
usable. I don't have yet the regular expression describing the language
in a human-friendly form but I got a finite automaton picture that
describes it (see https://www.debuggex.com/i/_Pg9KOp2TgXuus8K.png).
Basically, you have the parentheses form of rules from Bind Rules,
separated with either "and/or" or "except" keyword. "except" should only
appear once. You would set the time ranges with the "-" operator, e.g.
timeofday=0800-1545 (this operator is not shown in the picture). The
parenthesis could also be nested but that can't of course be described
by a finite automaton. The "except" keyword should still appear only
once, though. If any time-describing part is missing, it means that
access is allowed (e.g. (timeofday=0800-1600 dayofweek=Mon-Fri) allows
access from 8:00 to 16:00 Monday through Friday any week in the month,
any month in the year). This language should be able to do everything
the old language did, supports reoccurring events nicely and also allows
exceptions, so importing iCalendar events might be possible. However,
its downfall is that it's not very space-effici

[Freeipa-devel] Time-based account policies

[Stanislav Láznička]

Hi!

I went through the last week's thread on Time-Based Policies, discussed 
some parts I wasn't very sure about with Martin, and would like to make 
a summary of it, followed by some further questions on the topic. The 
mail is a bit longer than I thought it would be. Sorry about that. It 
seems I am very bad at fast and brief responses.


So to summarize - the best way to go seems to be to implement both UTC 
and client-side local time support. A very nice idea is to store it in 
the format (time, timezone). Now if I understand this right, the 
timezone here would be the Olson database timezone stored with the 
host/hostgroup, possibly overridden by service/servicegroup timezone. It 
would help the administrator decide the correct UTC time by adjusting 
the time displayed in UI/CLI. The administrator should also be able to 
set this timezone in the UI/CLI settings of the HBAC rule (or maybe they 
just set it instead of storing timezone info with host/hostgroup etc. 
objects?).


As for the local time - timezone in the tuple (time, timezone) would 
only say "Local Time", which can't be found in Olson's and it means the 
time record from the tuple should be compared to the client's time 
settings (/etc/localtime ?).


What would then be left to decide is whether to use the iCalendar time 
format as internal, or use some other own created format. Such a format 
should not only be suitable for reoccurring events, but should also be 
able to handle exceptions in those events, such as holidays. It should 
also be easy to import iCalendar events to this format to support events 
from other sources.


The iCalendar format is rather heavy and if we wanted to use it as a 
whole, it may be necessary to include third party libraries in the SSSD 
project along with their possible vulnerabilities. There is a 
possibility of using only part of the iCalendar format that handles 
reoccurring events and exceptions. Example from Alexander to be found 
here: 
https://github.com/libical/libical/blob/master/src/test/icalrecur_test.c. That 
may or may not work perfectly well, given the libical library is a 
complex thing and we'd be taking just a part of it.


The other time format option is to simplify/edit the language that was 
used in the past (described with regular expressions here: 
https://git.fedorahosted.org/cgit/sssd.git/commit/?id=1ce240367a2144500187ccd3c0d32c975d8d346a). 
There was probably a reason to step out of the language (the possibility 
of parsing those iCalendar events, I guess) and it may or may not be 
possible to fix the language so that the problems with it are dealt with.


I was also inspired by the language of the time part of Bind Rules from 
389 Directory Server and created a possible language that might be 
usable. I don't have yet the regular expression describing the language 
in a human-friendly form but I got a finite automaton picture that 
describes it (see https://www.debuggex.com/i/_Pg9KOp2TgXuus8K.png). 
Basically, you have the parentheses form of rules from Bind Rules, 
separated with either "and/or" or "except" keyword. "except" should only 
appear once. You would set the time ranges with the "-" operator, e.g. 
timeofday=0800-1545 (this operator is not shown in the picture). The 
parenthesis could also be nested but that can't of course be described 
by a finite automaton. The "except" keyword should still appear only 
once, though. If any time-describing part is missing, it means that 
access is allowed (e.g. (timeofday=0800-1600 dayofweek=Mon-Fri) allows 
access from 8:00 to 16:00 Monday through Friday any week in the month, 
any month in the year). This language should be able to do everything 
the old language did, supports reoccurring events nicely and also allows 
exceptions, so importing iCalendar events might be possible. However, 
its downfall is that it's not very space-efficient and absolute time 
ranges may not be so easily be described (e.g. time from 18:00 20.3.2015 
to 23:00 24.12.2015 would be quite a string).


MY QUESTIONS: Do we store the timezone information with the 
host/hostgroup, service/servicegroup object or do we just have the admin 
pick the timezone themselves? Which time format would be best for both 
FreeIPA and SSSD?


Thank you very much for you insights!
Standa

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[John Dennis]

On 03/10/2015 11:06 AM, Jakub Hrozek wrote:
>> We may need to use libraries for processing iCal rules, like libical
>> (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...
> 
> Is that what Alexander said, though? In his reply, I see:
> "Parsing event information would produce a rule definition we would
> store and SSSD would apply as HBAC rule".
> 
> I don't think iCal dependency is something we want in SSSD, the
> rules should be converted from iCal to SSSD format in a layer atop
> libipa_hbac..

But doesn't the iCal rule have to be evaluated in SSSD? If so that
requires linking against libical, right?


-- 
John

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 10 Mar 2015, John Dennis wrote:

On 03/10/2015 12:56 PM, Alexander Bokovoy wrote:

See my answer to John. We don't need to end up with iCal at all since
iCal doesn't have procedural definitions of holidays. It has
EXDATE/RRULE allowing to express exceptions and repeating rules (EXRULE
for exception rules was removed in RFC5545 and is not used anymore) but
nothing more concrete.

RFC5545 does define multiple things which are part of iCalendar format
and which we don't really need to deal with in SSSD so we don't need
full iCal at all. We need to be able to represent recurring events and
some of exceptions to them within the rules but that is a subset of what
is needed and can be implemented without involving a fully-compliant
iCal library.


I always get a bit concerned when I hear we'll factor out or just import
only the minimal code we need to support the minimal functionality we
need from an otherwise large complex body of code implementing an entire
RFC.

Maybe the code in libical is perfectly suited to extracting the snippets
we need (I don't know) but experience tells me complex code has complex
inter-dependencies and reducing libical to our minimal requirements
might be a significant effort. Is there really a problem with just
linking with the entire libical library even if it's more than we need?

I'd leave that to Jakub to decide. Here is a typical sample of what we
would need from libical: parsing of recurrence rules:
https://github.com/libical/libical/blob/master/src/test/icalrecur_test.c
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[John Dennis]

On 03/10/2015 12:56 PM, Alexander Bokovoy wrote:
> See my answer to John. We don't need to end up with iCal at all since
> iCal doesn't have procedural definitions of holidays. It has
> EXDATE/RRULE allowing to express exceptions and repeating rules (EXRULE
> for exception rules was removed in RFC5545 and is not used anymore) but
> nothing more concrete.
> 
> RFC5545 does define multiple things which are part of iCalendar format
> and which we don't really need to deal with in SSSD so we don't need
> full iCal at all. We need to be able to represent recurring events and
> some of exceptions to them within the rules but that is a subset of what
> is needed and can be implemented without involving a fully-compliant
> iCal library.

I always get a bit concerned when I hear we'll factor out or just import
only the minimal code we need to support the minimal functionality we
need from an otherwise large complex body of code implementing an entire
RFC.

Maybe the code in libical is perfectly suited to extracting the snippets
we need (I don't know) but experience tells me complex code has complex
inter-dependencies and reducing libical to our minimal requirements
might be a significant effort. Is there really a problem with just
linking with the entire libical library even if it's more than we need?



-- 
John

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 10 Mar 2015, Martin Kosek wrote:

On 03/10/2015 05:18 PM, Alexander Bokovoy wrote:

On Tue, 10 Mar 2015, John Dennis wrote:

On 03/10/2015 11:06 AM, Jakub Hrozek wrote:

We may need to use libraries for processing iCal rules, like libical
(http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...


Is that what Alexander said, though? In his reply, I see:
"Parsing event information would produce a rule definition we would
store and SSSD would apply as HBAC rule".

I don't think iCal dependency is something we want in SSSD, the
rules should be converted from iCal to SSSD format in a layer atop
libipa_hbac..


But doesn't the iCal rule have to be evaluated in SSSD? If so that
requires linking against libical, right?

That's why I'm saying we import iCal in IPA, not that we keep using iCal
as internal representation of time/date information for HBAC rules.

I don't really want to impose iCal horror on HBAC rule parsing engine.
I believe we can do simpler and better, given HBAC is all about ALLOW
rules on the base of default DENY action.


Ok, but how do you want to define rule as

"Allow Joe to log in every Monday, except holidays (when the office is closed)"?

We can't just have IPA processed the Ical and generate Allow ranges as there is
indefinite number of the allow ranges. So if you want to described more complex
rule (reocurring rule with some exceptions maybe), you end up with iCal anyway.
Or not?

See my answer to John. We don't need to end up with iCal at all since
iCal doesn't have procedural definitions of holidays. It has
EXDATE/RRULE allowing to express exceptions and repeating rules (EXRULE
for exception rules was removed in RFC5545 and is not used anymore) but
nothing more concrete.

RFC5545 does define multiple things which are part of iCalendar format
and which we don't really need to deal with in SSSD so we don't need
full iCal at all. We need to be able to represent recurring events and
some of exceptions to them within the rules but that is a subset of what
is needed and can be implemented without involving a fully-compliant
iCal library.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Stanislav Láznička]

On 03/10/2015 04:06 PM, Jakub Hrozek wrote:

On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote:

This is where importing iCal is helpful because it allows you to
outsource the task of creating such event to something else.

Parsing event information would produce a rule definition we would store
and SSSD would apply as HBAC rule. However, we don't need ourselves to
provide a complex UI to define such rules. Instead, we can do a simple
UI to create rules plus a UI to import rules defined in iCal by some
other software. The rest is visualizing HBAC time/date rules which is
separate from dealing with complexity of creating or importing rules.

Additionally, for iCal-based imports we can utilize participants
information from the iCal to automatically set up members of the rule
(based on mail attribute).


Ah, makes sense to me.

With all the possibilities that iCal format offers, we would more or less end
up storing iCal in HBAC rules (or our own format of iCal). I am just concerned
it would make a bit complex processing on SSSD side, especially in the security
sensitive piece for authorization rules.

We may need to use libraries for processing iCal rules, like libical
(http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...

Is that what Alexander said, though? In his reply, I see:
 "Parsing event information would produce a rule definition we would
 store and SSSD would apply as HBAC rule".
This is what kind of worried me, too. If I understand it well, this 
means you would have iCal events such as holidays (these were mentioned 
before), and you would like to generate HBAC rules based on these 
events. Those rules would, however, be different for each country (if 
this is still about holidays) and might collide among user and host 
groups. Therefore, you would have lots and lots of rules in the end, 
wouldn't you?


I wonder if anyone does that. From what I've seen in AD and 389 
Directory Server, time-based rules are being stored in a rather simple 
manner. I don't mind a more complex solution but I think such exceptions 
might be little too much. But I might have not understood the idea very 
well.

I don't think iCal dependency is something we want in SSSD, the
rules should be converted from iCal to SSSD format in a layer atop
libipa_hbac..



--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 10 Mar 2015, Gabe Alford wrote:

On Tue, Mar 10, 2015 at 9:51 AM, Stanislav Láznička  wrote:


On 03/10/2015 04:06 PM, Jakub Hrozek wrote:


On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote:


This is where importing iCal is helpful because it allows you to

outsource the task of creating such event to something else.

Parsing event information would produce a rule definition we would store
and SSSD would apply as HBAC rule. However, we don't need ourselves to
provide a complex UI to define such rules. Instead, we can do a simple
UI to create rules plus a UI to import rules defined in iCal by some
other software. The rest is visualizing HBAC time/date rules which is
separate from dealing with complexity of creating or importing rules.

Additionally, for iCal-based imports we can utilize participants
information from the iCal to automatically set up members of the rule
(based on mail attribute).

 Ah, makes sense to me.


With all the possibilities that iCal format offers, we would more or
less end
up storing iCal in HBAC rules (or our own format of iCal). I am just
concerned
it would make a bit complex processing on SSSD side, especially in the
security
sensitive piece for authorization rules.

We may need to use libraries for processing iCal rules, like libical
(http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...


Is that what Alexander said, though? In his reply, I see:
 "Parsing event information would produce a rule definition we would
 store and SSSD would apply as HBAC rule".


This is what kind of worried me, too. If I understand it well, this means
you would have iCal events such as holidays (these were mentioned before),
and you would like to generate HBAC rules based on these events. Those
rules would, however, be different for each country (if this is still about
holidays) and might collide among user and host groups. Therefore, you
would have lots and lots of rules in the end, wouldn't you?

I wonder if anyone does that. From what I've seen in AD and 389 Directory
Server, time-based rules are being stored in a rather simple manner. I
don't mind a more complex solution but I think such exceptions might be
little too much. But I might have not understood the idea very well.



This is my understanding as well. If using AD as the example, there are two
ways that timebased rules are configured:
1. Permit logon hours during specified timeframe on specified day(s)
of the week.
2. Deny logon hours during specified timeframe on specified day(s) of
the week.

There is nothing about holidays. I think that implementing holidays and
special exemptions should be avoided.

Yep. Except that we DENY by default in HBAC rules. So we only handle
ALLOW case already and there are strong reasons not to structure HBAC
rules to provide DENY too.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 10 Mar 2015, John Dennis wrote:

On 03/10/2015 12:13 PM, Alexander Bokovoy wrote:

HBAC rule is a tuple (user|group, host|hostgroup, service|servicegroup).
This tuple would get extension representing time/date information in a
multivalued attribute that would describe all time/date intervals
applicable to this rule.


I must be misunderstanding something. Recurrence rules yield an
unbounded number of "allow" intervals. Certainly you do not want to
enumerate and store all the intervals, instead you want to evaluate the
rule locally and obtain a simple yes/no answer, don't you?

Yes. We are not contradicting each other as there is nothing in my
response quoted above that implies that description of these time/date
intervals is explicit rather than functional.

We really need to define the format of such description but it doesn't
need to be iCal as it is.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/10/2015 05:18 PM, Alexander Bokovoy wrote:
> On Tue, 10 Mar 2015, John Dennis wrote:
>> On 03/10/2015 11:06 AM, Jakub Hrozek wrote:
 We may need to use libraries for processing iCal rules, like libical
 (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...
>>>
>>> Is that what Alexander said, though? In his reply, I see:
>>> "Parsing event information would produce a rule definition we would
>>> store and SSSD would apply as HBAC rule".
>>>
>>> I don't think iCal dependency is something we want in SSSD, the
>>> rules should be converted from iCal to SSSD format in a layer atop
>>> libipa_hbac..
>>
>> But doesn't the iCal rule have to be evaluated in SSSD? If so that
>> requires linking against libical, right?
> That's why I'm saying we import iCal in IPA, not that we keep using iCal
> as internal representation of time/date information for HBAC rules.
> 
> I don't really want to impose iCal horror on HBAC rule parsing engine.
> I believe we can do simpler and better, given HBAC is all about ALLOW
> rules on the base of default DENY action.

Ok, but how do you want to define rule as

"Allow Joe to log in every Monday, except holidays (when the office is closed)"?

We can't just have IPA processed the Ical and generate Allow ranges as there is
indefinite number of the allow ranges. So if you want to described more complex
rule (reocurring rule with some exceptions maybe), you end up with iCal anyway.
Or not?

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[John Dennis]

On 03/10/2015 12:13 PM, Alexander Bokovoy wrote:
> HBAC rule is a tuple (user|group, host|hostgroup, service|servicegroup).
> This tuple would get extension representing time/date information in a
> multivalued attribute that would describe all time/date intervals
> applicable to this rule.

I must be misunderstanding something. Recurrence rules yield an
unbounded number of "allow" intervals. Certainly you do not want to
enumerate and store all the intervals, instead you want to evaluate the
rule locally and obtain a simple yes/no answer, don't you?

-- 
John

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 10 Mar 2015, John Dennis wrote:

On 03/10/2015 11:06 AM, Jakub Hrozek wrote:

We may need to use libraries for processing iCal rules, like libical
(http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...


Is that what Alexander said, though? In his reply, I see:
"Parsing event information would produce a rule definition we would
store and SSSD would apply as HBAC rule".

I don't think iCal dependency is something we want in SSSD, the
rules should be converted from iCal to SSSD format in a layer atop
libipa_hbac..


But doesn't the iCal rule have to be evaluated in SSSD? If so that
requires linking against libical, right?

That's why I'm saying we import iCal in IPA, not that we keep using iCal
as internal representation of time/date information for HBAC rules.

I don't really want to impose iCal horror on HBAC rule parsing engine.
I believe we can do simpler and better, given HBAC is all about ALLOW
rules on the base of default DENY action.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 10 Mar 2015, Stanislav Láznička wrote:

On 03/10/2015 04:06 PM, Jakub Hrozek wrote:

On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote:

This is where importing iCal is helpful because it allows you to
outsource the task of creating such event to something else.

Parsing event information would produce a rule definition we would store
and SSSD would apply as HBAC rule. However, we don't need ourselves to
provide a complex UI to define such rules. Instead, we can do a simple
UI to create rules plus a UI to import rules defined in iCal by some
other software. The rest is visualizing HBAC time/date rules which is
separate from dealing with complexity of creating or importing rules.

Additionally, for iCal-based imports we can utilize participants
information from the iCal to automatically set up members of the rule
(based on mail attribute).


Ah, makes sense to me.

With all the possibilities that iCal format offers, we would more or less end
up storing iCal in HBAC rules (or our own format of iCal). I am just concerned
it would make a bit complex processing on SSSD side, especially in the security
sensitive piece for authorization rules.

We may need to use libraries for processing iCal rules, like libical
(http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...

Is that what Alexander said, though? In his reply, I see:
"Parsing event information would produce a rule definition we would
store and SSSD would apply as HBAC rule".
This is what kind of worried me, too. If I understand it well, this 
means you would have iCal events such as holidays (these were 
mentioned before), and you would like to generate HBAC rules based on 
these events. Those rules would, however, be different for each 
country (if this is still about holidays) and might collide among user 
and host groups. Therefore, you would have lots and lots of rules in 
the end, wouldn't you?
It does not matter how many rules are there. 
SSSD caches HBAC rules per host and if rule doesn't apply, it is not

downloaded and doesn't affect the host.

HBAC rule is a tuple (user|group, host|hostgroup, service|servicegroup).
This tuple would get extension representing time/date information in a
multivalued attribute that would describe all time/date intervals
applicable to this rule.

HBAC rules represent ALLOW action and default is DENY so you don't need
to represent holidays, they are on DENY by default. You only need to
represent ALLOW here.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Gabe Alford]

On Tue, Mar 10, 2015 at 9:51 AM, Stanislav Láznička  wrote:

> On 03/10/2015 04:06 PM, Jakub Hrozek wrote:
>
>> On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote:
>>
>>> This is where importing iCal is helpful because it allows you to
 outsource the task of creating such event to something else.

 Parsing event information would produce a rule definition we would store
 and SSSD would apply as HBAC rule. However, we don't need ourselves to
 provide a complex UI to define such rules. Instead, we can do a simple
 UI to create rules plus a UI to import rules defined in iCal by some
 other software. The rest is visualizing HBAC time/date rules which is
 separate from dealing with complexity of creating or importing rules.

 Additionally, for iCal-based imports we can utilize participants
 information from the iCal to automatically set up members of the rule
 (based on mail attribute).

  Ah, makes sense to me.
>>>
>>> With all the possibilities that iCal format offers, we would more or
>>> less end
>>> up storing iCal in HBAC rules (or our own format of iCal). I am just
>>> concerned
>>> it would make a bit complex processing on SSSD side, especially in the
>>> security
>>> sensitive piece for authorization rules.
>>>
>>> We may need to use libraries for processing iCal rules, like libical
>>> (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...
>>>
>> Is that what Alexander said, though? In his reply, I see:
>>  "Parsing event information would produce a rule definition we would
>>  store and SSSD would apply as HBAC rule".
>>
> This is what kind of worried me, too. If I understand it well, this means
> you would have iCal events such as holidays (these were mentioned before),
> and you would like to generate HBAC rules based on these events. Those
> rules would, however, be different for each country (if this is still about
> holidays) and might collide among user and host groups. Therefore, you
> would have lots and lots of rules in the end, wouldn't you?
>
> I wonder if anyone does that. From what I've seen in AD and 389 Directory
> Server, time-based rules are being stored in a rather simple manner. I
> don't mind a more complex solution but I think such exceptions might be
> little too much. But I might have not understood the idea very well.


This is my understanding as well. If using AD as the example, there are two
ways that timebased rules are configured:
 1. Permit logon hours during specified timeframe on specified day(s)
of the week.
 2. Deny logon hours during specified timeframe on specified day(s) of
the week.

There is nothing about holidays. I think that implementing holidays and
special exemptions should be avoided.

Just my 2 cents.

Gabe


>  I don't think iCal dependency is something we want in SSSD, the
>> rules should be converted from iCal to SSSD format in a layer atop
>> libipa_hbac..
>>
>>
> --
> Manage your subscription for the Freeipa-devel mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-devel
> Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
>
-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Jakub Hrozek]

On Tue, Mar 10, 2015 at 03:47:10PM +0100, Martin Kosek wrote:
> > This is where importing iCal is helpful because it allows you to
> > outsource the task of creating such event to something else.
> > 
> > Parsing event information would produce a rule definition we would store
> > and SSSD would apply as HBAC rule. However, we don't need ourselves to
> > provide a complex UI to define such rules. Instead, we can do a simple
> > UI to create rules plus a UI to import rules defined in iCal by some
> > other software. The rest is visualizing HBAC time/date rules which is
> > separate from dealing with complexity of creating or importing rules.
> > 
> > Additionally, for iCal-based imports we can utilize participants
> > information from the iCal to automatically set up members of the rule
> > (based on mail attribute).
> > 
> 
> Ah, makes sense to me.
> 
> With all the possibilities that iCal format offers, we would more or less end
> up storing iCal in HBAC rules (or our own format of iCal). I am just concerned
> it would make a bit complex processing on SSSD side, especially in the 
> security
> sensitive piece for authorization rules.
> 
> We may need to use libraries for processing iCal rules, like libical
> (http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...

Is that what Alexander said, though? In his reply, I see:
"Parsing event information would produce a rule definition we would
store and SSSD would apply as HBAC rule".

I don't think iCal dependency is something we want in SSSD, the
rules should be converted from iCal to SSSD format in a layer atop
libipa_hbac..

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/10/2015 03:40 PM, Alexander Bokovoy wrote:
> On Tue, 10 Mar 2015, Martin Kosek wrote:
>> On 03/09/2015 07:22 PM, Alexander Bokovoy wrote:
>>> On Mon, 09 Mar 2015, Jakub Hrozek wrote:
 On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
> On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> > On Mon, 09 Mar 2015, Martin Kosek wrote:
> ...
> > One of bigger issues we had was lack of versatile ical format parser to
> > handle calendar-like specification of events -- we need to allow
> > importing these ones instead of inventing our own.
>
> Good point. I wonder how rigorous we want to be. iCal is a pretty powerful
> calendaring format. If we want to implement full support for it, it would 
> be
> lot of code both on server side for setting it and on client side for
> evaluating it (CCing Jakub for reference).
>
> AD itself has much simpler UI for setting the access time, a table like 
> that:
> http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
>
>
>
> IIRC, they only store the bits of "can login/cannot login" for the time
> slots.
> That's another alternative.

 I don't think that's what Alexander meant, I don't think the client
 library should come anywhere close to the iCal format. We might want to
 provide a script to convert an external format, but that's about it.

 I thought we could simply reuse parts of the previous grammar, maybe
 simplified. But I agree with Nathaniel (as I stated also in the private
 thread) that we should use UTC where possible.
>>> Yes and no. Let me go in details a bit.
>>>
>>> We need iCal support to allow importing events created by external
>>> tools. We don't need to use it as internal format.
>>
>> Can you please share a bit what events you have in mind? We are talking about
>> HBAC access rules, so I am not sure what you want to import.
>>
>> Is this for use cases like - I have a recurring Linux learning lab, I want to
>> all participants to be able to log in to this system during the lab run?
>>
>> This may results in pretty complicated time related rules in HBAC, where you
>> may need to deal with reocurrence, exceptions, etc. So far more complex than
>> the AD use cases
>> (http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg).
>>
> This is where importing iCal is helpful because it allows you to
> outsource the task of creating such event to something else.
> 
> Parsing event information would produce a rule definition we would store
> and SSSD would apply as HBAC rule. However, we don't need ourselves to
> provide a complex UI to define such rules. Instead, we can do a simple
> UI to create rules plus a UI to import rules defined in iCal by some
> other software. The rest is visualizing HBAC time/date rules which is
> separate from dealing with complexity of creating or importing rules.
> 
> Additionally, for iCal-based imports we can utilize participants
> information from the iCal to automatically set up members of the rule
> (based on mail attribute).
> 

Ah, makes sense to me.

With all the possibilities that iCal format offers, we would more or less end
up storing iCal in HBAC rules (or our own format of iCal). I am just concerned
it would make a bit complex processing on SSSD side, especially in the security
sensitive piece for authorization rules.

We may need to use libraries for processing iCal rules, like libical
(http://koji.fedoraproject.org/koji/buildinfo?buildID=606329)...

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 10 Mar 2015, Martin Kosek wrote:

On 03/10/2015 03:34 PM, Alexander Bokovoy wrote:

On Tue, 10 Mar 2015, Simo Sorce wrote:

On Tue, 2015-03-10 at 14:54 +0100, Martin Kosek wrote:

On 03/09/2015 09:05 PM, Nathaniel McCallum wrote:
> On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote:
>> On Mon, 09 Mar 2015, Simo Sorce wrote:
...
>>> For some tasks 'local' is the only thing that makes sense (your
>>> morning alarm clock), for other things 'UTC' is the only thing
>>> that make sense (coordinated changes across multiple distributed
>>> data centers).
>>>
>>> Implementing just one or the other is not useful.
>> Correct. At this point I think we are more or less in agreement that
>> we need to store time rules in UTC plus timezone correction
>> information specific to the execution context (HBAC rule, host,
>> etc). Handling 'UTC' rule is equivalent to selecting specific
>> timezone (GMT+0, for example) so this is a case of more general (UTC
>> time, timezone definiton) pairs.
>>
>> This timezone definition may have aliases forcing HBAC intepretation
>> to use local machine defaults if needed but the general scheme stays
>> the same.
>
> Agreed.

Alexander, can you please elaborate a bit more on the idea of storing the time
rules in UTC + timezone correction? I thought SSSD would take take the time
zone information from the local system.

The purpose is that admin can create rule like "Joe can interactively log in
from 8:00 to 17:00 on all machines across the globe". You cannot store the time
zone with such rule as the rule spans across several many different time zones.
Right?


Yes this is a rule expressed in "Local Time" which is a time-zone-less
rule.

Yep, and timezone info for this rule is "Local Time" which is a timezone
that doesn't exist in Olson database and would be interpreted by SSSD
as "default server timezone".


I still do not understand.

With Local Time HBAC rule, I thought that the time zone information/setting
would only exist on the local machine. Maybe if you provide example of exact
setting that would be stored in LDAP and what should be the implications on the
clients in different time zones, I would understand better.

Instead of a single time point in UTC we would have a pair (time,
tzinfo) where tzinfo is just a timezone info from Olson database
(tzdata). 'time' element would be expressed in UTC.

We would use Olson database to find out available timezones. If tzinfo
is 'Local Time', we simply record it this way in LDAP record and then
SSSD on the client would parse it in such way that instead of forcing TZ
to the tzinfo string it would use default /etc/localtime on the host.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 10 Mar 2015, Martin Kosek wrote:

On 03/09/2015 07:22 PM, Alexander Bokovoy wrote:

On Mon, 09 Mar 2015, Jakub Hrozek wrote:

On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:

On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> On Mon, 09 Mar 2015, Martin Kosek wrote:
...
> One of bigger issues we had was lack of versatile ical format parser to
> handle calendar-like specification of events -- we need to allow
> importing these ones instead of inventing our own.

Good point. I wonder how rigorous we want to be. iCal is a pretty powerful
calendaring format. If we want to implement full support for it, it would be
lot of code both on server side for setting it and on client side for
evaluating it (CCing Jakub for reference).

AD itself has much simpler UI for setting the access time, a table like that:
http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg


IIRC, they only store the bits of "can login/cannot login" for the time slots.
That's another alternative.


I don't think that's what Alexander meant, I don't think the client
library should come anywhere close to the iCal format. We might want to
provide a script to convert an external format, but that's about it.

I thought we could simply reuse parts of the previous grammar, maybe
simplified. But I agree with Nathaniel (as I stated also in the private
thread) that we should use UTC where possible.

Yes and no. Let me go in details a bit.

We need iCal support to allow importing events created by external
tools. We don't need to use it as internal format.


Can you please share a bit what events you have in mind? We are talking about
HBAC access rules, so I am not sure what you want to import.

Is this for use cases like - I have a recurring Linux learning lab, I want to
all participants to be able to log in to this system during the lab run?

This may results in pretty complicated time related rules in HBAC, where you
may need to deal with reocurrence, exceptions, etc. So far more complex than
the AD use cases
(http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg).

This is where importing iCal is helpful because it allows you to
outsource the task of creating such event to something else.

Parsing event information would produce a rule definition we would store
and SSSD would apply as HBAC rule. However, we don't need ourselves to
provide a complex UI to define such rules. Instead, we can do a simple
UI to create rules plus a UI to import rules defined in iCal by some
other software. The rest is visualizing HBAC time/date rules which is
separate from dealing with complexity of creating or importing rules.

Additionally, for iCal-based imports we can utilize participants
information from the iCal to automatically set up members of the rule
(based on mail attribute).

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/10/2015 03:34 PM, Alexander Bokovoy wrote:
> On Tue, 10 Mar 2015, Simo Sorce wrote:
>> On Tue, 2015-03-10 at 14:54 +0100, Martin Kosek wrote:
>>> On 03/09/2015 09:05 PM, Nathaniel McCallum wrote:
>>> > On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote:
>>> >> On Mon, 09 Mar 2015, Simo Sorce wrote:
>>> ...
>>> >>> For some tasks 'local' is the only thing that makes sense (your
>>> >>> morning alarm clock), for other things 'UTC' is the only thing
>>> >>> that make sense (coordinated changes across multiple distributed
>>> >>> data centers).
>>> >>>
>>> >>> Implementing just one or the other is not useful.
>>> >> Correct. At this point I think we are more or less in agreement that
>>> >> we need to store time rules in UTC plus timezone correction
>>> >> information specific to the execution context (HBAC rule, host,
>>> >> etc). Handling 'UTC' rule is equivalent to selecting specific
>>> >> timezone (GMT+0, for example) so this is a case of more general (UTC
>>> >> time, timezone definiton) pairs.
>>> >>
>>> >> This timezone definition may have aliases forcing HBAC intepretation
>>> >> to use local machine defaults if needed but the general scheme stays
>>> >> the same.
>>> >
>>> > Agreed.
>>>
>>> Alexander, can you please elaborate a bit more on the idea of storing the 
>>> time
>>> rules in UTC + timezone correction? I thought SSSD would take take the time
>>> zone information from the local system.
>>>
>>> The purpose is that admin can create rule like "Joe can interactively log in
>>> from 8:00 to 17:00 on all machines across the globe". You cannot store the 
>>> time
>>> zone with such rule as the rule spans across several many different time 
>>> zones.
>>> Right?
>>
>> Yes this is a rule expressed in "Local Time" which is a time-zone-less
>> rule.
> Yep, and timezone info for this rule is "Local Time" which is a timezone
> that doesn't exist in Olson database and would be interpreted by SSSD
> as "default server timezone".

I still do not understand.

With Local Time HBAC rule, I thought that the time zone information/setting
would only exist on the local machine. Maybe if you provide example of exact
setting that would be stored in LDAP and what should be the implications on the
clients in different time zones, I would understand better.

Thanks,
Martin

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Tue, 10 Mar 2015, Simo Sorce wrote:

On Tue, 2015-03-10 at 14:54 +0100, Martin Kosek wrote:

On 03/09/2015 09:05 PM, Nathaniel McCallum wrote:
> On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote:
>> On Mon, 09 Mar 2015, Simo Sorce wrote:
...
>>> For some tasks 'local' is the only thing that makes sense (your
>>> morning alarm clock), for other things 'UTC' is the only thing
>>> that make sense (coordinated changes across multiple distributed
>>> data centers).
>>>
>>> Implementing just one or the other is not useful.
>> Correct. At this point I think we are more or less in agreement that
>> we need to store time rules in UTC plus timezone correction
>> information specific to the execution context (HBAC rule, host,
>> etc). Handling 'UTC' rule is equivalent to selecting specific
>> timezone (GMT+0, for example) so this is a case of more general (UTC
>> time, timezone definiton) pairs.
>>
>> This timezone definition may have aliases forcing HBAC intepretation
>> to use local machine defaults if needed but the general scheme stays
>> the same.
>
> Agreed.

Alexander, can you please elaborate a bit more on the idea of storing the time
rules in UTC + timezone correction? I thought SSSD would take take the time
zone information from the local system.

The purpose is that admin can create rule like "Joe can interactively log in
from 8:00 to 17:00 on all machines across the globe". You cannot store the time
zone with such rule as the rule spans across several many different time zones.
Right?


Yes this is a rule expressed in "Local Time" which is a time-zone-less
rule.

Yep, and timezone info for this rule is "Local Time" which is a timezone
that doesn't exist in Olson database and would be interpreted by SSSD
as "default server timezone".
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

On Tue, 2015-03-10 at 15:00 +0100, Martin Kosek wrote:
> On 03/09/2015 07:22 PM, Alexander Bokovoy wrote:
> > On Mon, 09 Mar 2015, Jakub Hrozek wrote:
> >> On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
> >>> On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> >>> > On Mon, 09 Mar 2015, Martin Kosek wrote:
> >>> ...
> >>> > One of bigger issues we had was lack of versatile ical format parser to
> >>> > handle calendar-like specification of events -- we need to allow
> >>> > importing these ones instead of inventing our own.
> >>>
> >>> Good point. I wonder how rigorous we want to be. iCal is a pretty powerful
> >>> calendaring format. If we want to implement full support for it, it would 
> >>> be
> >>> lot of code both on server side for setting it and on client side for
> >>> evaluating it (CCing Jakub for reference).
> >>>
> >>> AD itself has much simpler UI for setting the access time, a table like 
> >>> that:
> >>> http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
> >>>
> >>>
> >>> IIRC, they only store the bits of "can login/cannot login" for the time 
> >>> slots.
> >>> That's another alternative.
> >>
> >> I don't think that's what Alexander meant, I don't think the client
> >> library should come anywhere close to the iCal format. We might want to
> >> provide a script to convert an external format, but that's about it.
> >>
> >> I thought we could simply reuse parts of the previous grammar, maybe
> >> simplified. But I agree with Nathaniel (as I stated also in the private
> >> thread) that we should use UTC where possible.
> > Yes and no. Let me go in details a bit.
> > 
> > We need iCal support to allow importing events created by external
> > tools. We don't need to use it as internal format.
> 
> Can you please share a bit what events you have in mind? We are talking about
> HBAC access rules, so I am not sure what you want to import.
> 
> Is this for use cases like - I have a recurring Linux learning lab, I want to
> all participants to be able to log in to this system during the lab run?

You still need this, if you really want time based rules, then pretty
soon you'll get requests to add special exceptions, like holidays, and
who knows what else.

Last time around we came to the conclusion that this was very
complicated and dropped it for that reason. A non-complicated tool is
too simple to be useful, a complete one was deemed too complicated to
implement.

Damned if you, damned if you don't.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

On Tue, 2015-03-10 at 14:54 +0100, Martin Kosek wrote:
> On 03/09/2015 09:05 PM, Nathaniel McCallum wrote:
> > On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote:
> >> On Mon, 09 Mar 2015, Simo Sorce wrote:
> ...
> >>> For some tasks 'local' is the only thing that makes sense (your 
> >>> morning alarm clock), for other things 'UTC' is the only thing 
> >>> that make sense (coordinated changes across multiple distributed 
> >>> data centers).
> >>>
> >>> Implementing just one or the other is not useful.
> >> Correct. At this point I think we are more or less in agreement that 
> >> we need to store time rules in UTC plus timezone correction 
> >> information specific to the execution context (HBAC rule, host, 
> >> etc). Handling 'UTC' rule is equivalent to selecting specific 
> >> timezone (GMT+0, for example) so this is a case of more general (UTC 
> >> time, timezone definiton) pairs.
> >>
> >> This timezone definition may have aliases forcing HBAC intepretation 
> >> to use local machine defaults if needed but the general scheme stays 
> >> the same.
> > 
> > Agreed.
> 
> Alexander, can you please elaborate a bit more on the idea of storing the time
> rules in UTC + timezone correction? I thought SSSD would take take the time
> zone information from the local system.
> 
> The purpose is that admin can create rule like "Joe can interactively log in
> from 8:00 to 17:00 on all machines across the globe". You cannot store the 
> time
> zone with such rule as the rule spans across several many different time 
> zones.
> Right?

Yes this is a rule expressed in "Local Time" which is a time-zone-less
rule.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/09/2015 07:22 PM, Alexander Bokovoy wrote:
> On Mon, 09 Mar 2015, Jakub Hrozek wrote:
>> On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
>>> On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
>>> > On Mon, 09 Mar 2015, Martin Kosek wrote:
>>> ...
>>> > One of bigger issues we had was lack of versatile ical format parser to
>>> > handle calendar-like specification of events -- we need to allow
>>> > importing these ones instead of inventing our own.
>>>
>>> Good point. I wonder how rigorous we want to be. iCal is a pretty powerful
>>> calendaring format. If we want to implement full support for it, it would be
>>> lot of code both on server side for setting it and on client side for
>>> evaluating it (CCing Jakub for reference).
>>>
>>> AD itself has much simpler UI for setting the access time, a table like 
>>> that:
>>> http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
>>>
>>>
>>> IIRC, they only store the bits of "can login/cannot login" for the time 
>>> slots.
>>> That's another alternative.
>>
>> I don't think that's what Alexander meant, I don't think the client
>> library should come anywhere close to the iCal format. We might want to
>> provide a script to convert an external format, but that's about it.
>>
>> I thought we could simply reuse parts of the previous grammar, maybe
>> simplified. But I agree with Nathaniel (as I stated also in the private
>> thread) that we should use UTC where possible.
> Yes and no. Let me go in details a bit.
> 
> We need iCal support to allow importing events created by external
> tools. We don't need to use it as internal format.

Can you please share a bit what events you have in mind? We are talking about
HBAC access rules, so I am not sure what you want to import.

Is this for use cases like - I have a recurring Linux learning lab, I want to
all participants to be able to log in to this system during the lab run?

This may results in pretty complicated time related rules in HBAC, where you
may need to deal with reocurrence, exceptions, etc. So far more complex than
the AD use cases
(http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg).

Thanks,
Martin

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/09/2015 09:05 PM, Nathaniel McCallum wrote:
> On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote:
>> On Mon, 09 Mar 2015, Simo Sorce wrote:
...
>>> For some tasks 'local' is the only thing that makes sense (your 
>>> morning alarm clock), for other things 'UTC' is the only thing 
>>> that make sense (coordinated changes across multiple distributed 
>>> data centers).
>>>
>>> Implementing just one or the other is not useful.
>> Correct. At this point I think we are more or less in agreement that 
>> we need to store time rules in UTC plus timezone correction 
>> information specific to the execution context (HBAC rule, host, 
>> etc). Handling 'UTC' rule is equivalent to selecting specific 
>> timezone (GMT+0, for example) so this is a case of more general (UTC 
>> time, timezone definiton) pairs.
>>
>> This timezone definition may have aliases forcing HBAC intepretation 
>> to use local machine defaults if needed but the general scheme stays 
>> the same.
> 
> Agreed.

Alexander, can you please elaborate a bit more on the idea of storing the time
rules in UTC + timezone correction? I thought SSSD would take take the time
zone information from the local system.

The purpose is that admin can create rule like "Joe can interactively log in
from 8:00 to 17:00 on all machines across the globe". You cannot store the time
zone with such rule as the rule spans across several many different time zones.
Right?

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

On Mon, 2015-03-09 at 16:17 -0400, John Dennis wrote:
> On 03/09/2015 03:45 PM, Simo Sorce wrote:
> > We've been through this a few times already, it just doesn't work.
> > At a minimum you need to be able to select between UTC and "Local Time"
> > and it is a rathole down there (What time is it *here* may be a hard
> > question to answer :-/)
> 
> O.K. I'll bite, Converting from UTC to local using static UTC offsets is
> fraught with perils. But if you do the local conversion utilizing the tz
> (i.e. Olson) database why would be it hard to determine local time?

In some cases it may be hard due to external reasons (think travelers
and their devices).

Another problem is to understand who's timezone to match and how do you
know, if a user is connecting via the network and a local time rule is
in place, whose local time should that be ? The user or the server's ?

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[John Dennis]

On 03/09/2015 03:45 PM, Simo Sorce wrote:
> We've been through this a few times already, it just doesn't work.
> At a minimum you need to be able to select between UTC and "Local Time"
> and it is a rathole down there (What time is it *here* may be a hard
> question to answer :-/)

O.K. I'll bite, Converting from UTC to local using static UTC offsets is
fraught with perils. But if you do the local conversion utilizing the tz
(i.e. Olson) database why would be it hard to determine local time?

-- 
John

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Nathaniel McCallum]

On Mon, 2015-03-09 at 22:02 +0200, Alexander Bokovoy wrote:
> On Mon, 09 Mar 2015, Simo Sorce wrote:
> > On Mon, 2015-03-09 at 20:55 +0200, Alexander Bokovoy wrote:
> > > On Mon, 09 Mar 2015, Nathaniel McCallum wrote:
> > > > On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote:
> > > > > On Mon, 09 Mar 2015, Jakub Hrozek wrote:
> > > > > > On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek 
> > > > > > wrote:
> > > > > > > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> > > > > > > > On Mon, 09 Mar 2015, Martin Kosek wrote:
> > > > > > > ...
> > > > > > > > One of bigger issues we had was lack of versatile ical 
> > > > > > > > format
> > > > > > > > parser to handle calendar-like specification of events 
> > > > > > > > -- we
> > > > > > > > need to allow importing these ones instead of 
> > > > > > > > inventing our
> > > > > > > > own.
> > > > > > > 
> > > > > > > Good point. I wonder how rigorous we want to be. iCal is 
> > > > > > > a
> > > > > > > pretty powerful
> > > > > > > calendaring format. If we want to implement full support 
> > > > > > > for it, it would be
> > > > > > > lot of code both on server side for setting it and on 
> > > > > > > client
> > > > > > > side for evaluating it (CCing Jakub for reference).
> > > > > > > 
> > > > > > > AD itself has much simpler UI for setting the access 
> > > > > > > time, a
> > > > > > > table like that:
> > > > > > > http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
> > > > > > > 
> > > > > > > IIRC, they only store the bits of "can login/cannot 
> > > > > > > login" for the time slots.
> > > > > > > That's another alternative.
> > > > > > 
> > > > > > I don't think that's what Alexander meant, I don't think 
> > > > > > the
> > > > > > client library should come anywhere close to the iCal 
> > > > > > format. We might want to provide a script to convert an 
> > > > > > external format, but that's about it.
> > > > > > 
> > > > > > I thought we could simply reuse parts of the previous 
> > > > > > grammar, maybe simplified. But I agree with Nathaniel (as I
> > > > > > stated also in the private thread) that we should use UTC 
> > > > > > where possible.
> > > > > Yes and no. Let me go in details a bit.
> > > > > 
> > > > > We need iCal support to allow importing events created by 
> > > > > external tools. We don't need to use it as internal format.
> > > > > 
> > > > > However, there are quite a lot of details that can be lost 
> > > > > if only UTC would be in use for a date as you are ignoring a 
> > > > > timezone information completely. Timezone information needs 
> > > > > to be kept when importing and not always could be reliably 
> > > > > represented in UTC so that conversion from one timezone to 
> > > > > another could present quite a problem.
> > > > > 
> > > > > See   http://www.w3.org/TR/timezone/forsome of 
> > > > > recommendations.
> > > > 
> > > > I'm fine with a plan like this. I just want the admin to opt-
> > > > in to timezones. Localtime *by default* is fraught with 
> > > > pitfalls. If the admin needs local time policy, he should 
> > > > specify it exactly and should confirm the local time on 
> > > > affected systems.
> > > Yep. We need to make it easy -- probably by allowing to define 
> > > timezones as part of host object (like Martin proposed) and 
> > > overridden in HBAC service/service group. And all this have to 
> > > be very visual in the UI.
> > > 
> > > Another problem is how to deal with missing timezone information 
> > > at the place where HBAC rule with time rules would need to be 
> > > applied. We need to define the way we handle all these 
> > > (unavailable, non-parsable and other kinds of errors) timezone 
> > > info issues.
> > 
> > I would rather punt, than do some crappy thing ala Windows.

+1

> > Local Only or UTC only is always wrong.

+1. It was never my intent to imply this. :)

> > For some tasks 'local' is the only thing that makes sense (your 
> > morning alarm clock), for other things 'UTC' is the only thing 
> > that make sense (coordinated changes across multiple distributed 
> > data centers).
> > 
> > Implementing just one or the other is not useful.
> Correct. At this point I think we are more or less in agreement that 
> we need to store time rules in UTC plus timezone correction 
> information specific to the execution context (HBAC rule, host, 
> etc). Handling 'UTC' rule is equivalent to selecting specific 
> timezone (GMT+0, for example) so this is a case of more general (UTC 
> time, timezone definiton) pairs.
> 
> This timezone definition may have aliases forcing HBAC intepretation 
> to use local machine defaults if needed but the general scheme stays 
> the same.

Agreed.

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Mon, 09 Mar 2015, Simo Sorce wrote:

On Mon, 2015-03-09 at 20:55 +0200, Alexander Bokovoy wrote:

On Mon, 09 Mar 2015, Nathaniel McCallum wrote:
>On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote:
>> On Mon, 09 Mar 2015, Jakub Hrozek wrote:
>> > On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
>> > > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
>> > > > On Mon, 09 Mar 2015, Martin Kosek wrote:
>> > > ...
>> > > > One of bigger issues we had was lack of versatile ical format
>> > > > parser to handle calendar-like specification of events -- we
>> > > > need to allow importing these ones instead of inventing our
>> > > > own.
>> > >
>> > > Good point. I wonder how rigorous we want to be. iCal is a
>> > > pretty powerful
>> > > calendaring format. If we want to implement full support for it,
>> > > it would be
>> > > lot of code both on server side for setting it and on client
>> > > side for evaluating it (CCing Jakub for reference).
>> > >
>> > > AD itself has much simpler UI for setting the access time, a
>> > > table like that:
>> > > 
http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
>> > >
>> > > IIRC, they only store the bits of "can login/cannot login" for
>> > > the time slots.
>> > > That's another alternative.
>> >
>> > I don't think that's what Alexander meant, I don't think the
>> > client library should come anywhere close to the iCal format. We
>> > might want to provide a script to convert an external format, but
>> > that's about it.
>> >
>> > I thought we could simply reuse parts of the previous grammar,
>> > maybe simplified. But I agree with Nathaniel (as I stated also in
>> > the private thread) that we should use UTC where possible.
>> Yes and no. Let me go in details a bit.
>>
>> We need iCal support to allow importing events created by external
>> tools. We don't need to use it as internal format.
>>
>> However, there are quite a lot of details that can be lost if only
>> UTC would be in use for a date as you are ignoring a timezone
>> information completely. Timezone information needs to be kept when
>> importing and not always could be reliably represented in UTC so
>> that conversion from one timezone to another could present quite a
>> problem.
>>
>> See  http://www.w3.org/TR/timezone/for some of recommendations.
>
>I'm fine with a plan like this. I just want the admin to opt-in to
>timezones. Localtime *by default* is fraught with pitfalls. If the
>admin needs local time policy, he should specify it exactly and should
>confirm the local time on affected systems.
Yep. We need to make it easy -- probably by allowing to define timezones
as part of host object (like Martin proposed) and overridden in HBAC
service/service group. And all this have to be very visual in the UI.

Another problem is how to deal with missing timezone information at the
place where HBAC rule with time rules would need to be applied. We need
to define the way we handle all these (unavailable, non-parsable and
other kinds of errors) timezone info issues.


I would rather punt, than do some crappy thing ala Windows.

Local Only or UTC only is always wrong.

For some tasks 'local' is the only thing that makes sense (your morning
alarm clock), for other things 'UTC' is the only thing that make sense
(coordinated changes across multiple distributed data centers).

Implementing just one or the other is not useful.

Correct. At this point I think we are more or less in agreement that we
need to store time rules in UTC plus timezone correction information
specific to the execution context (HBAC rule, host, etc). Handling 'UTC'
rule is equivalent to selecting specific timezone (GMT+0, for example)
so this is a case of more general (UTC time, timezone definiton) pairs.

This timezone definition may have aliases forcing HBAC intepretation to
use local machine defaults if needed but the general scheme stays the
same.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

On Mon, 2015-03-09 at 20:55 +0200, Alexander Bokovoy wrote:
> On Mon, 09 Mar 2015, Nathaniel McCallum wrote:
> >On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote:
> >> On Mon, 09 Mar 2015, Jakub Hrozek wrote:
> >> > On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
> >> > > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> >> > > > On Mon, 09 Mar 2015, Martin Kosek wrote:
> >> > > ...
> >> > > > One of bigger issues we had was lack of versatile ical format
> >> > > > parser to handle calendar-like specification of events -- we
> >> > > > need to allow importing these ones instead of inventing our
> >> > > > own.
> >> > >
> >> > > Good point. I wonder how rigorous we want to be. iCal is a
> >> > > pretty powerful
> >> > > calendaring format. If we want to implement full support for it,
> >> > > it would be
> >> > > lot of code both on server side for setting it and on client
> >> > > side for evaluating it (CCing Jakub for reference).
> >> > >
> >> > > AD itself has much simpler UI for setting the access time, a
> >> > > table like that:
> >> > > http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
> >> > >
> >> > > IIRC, they only store the bits of "can login/cannot login" for
> >> > > the time slots.
> >> > > That's another alternative.
> >> >
> >> > I don't think that's what Alexander meant, I don't think the
> >> > client library should come anywhere close to the iCal format. We
> >> > might want to provide a script to convert an external format, but
> >> > that's about it.
> >> >
> >> > I thought we could simply reuse parts of the previous grammar,
> >> > maybe simplified. But I agree with Nathaniel (as I stated also in
> >> > the private thread) that we should use UTC where possible.
> >> Yes and no. Let me go in details a bit.
> >>
> >> We need iCal support to allow importing events created by external
> >> tools. We don't need to use it as internal format.
> >>
> >> However, there are quite a lot of details that can be lost if only
> >> UTC would be in use for a date as you are ignoring a timezone
> >> information completely. Timezone information needs to be kept when
> >> importing and not always could be reliably represented in UTC so
> >> that conversion from one timezone to another could present quite a
> >> problem.
> >>
> >> See  http://www.w3.org/TR/timezone/for some of recommendations.
> >
> >I'm fine with a plan like this. I just want the admin to opt-in to
> >timezones. Localtime *by default* is fraught with pitfalls. If the
> >admin needs local time policy, he should specify it exactly and should
> >confirm the local time on affected systems.
> Yep. We need to make it easy -- probably by allowing to define timezones
> as part of host object (like Martin proposed) and overridden in HBAC
> service/service group. And all this have to be very visual in the UI.
> 
> Another problem is how to deal with missing timezone information at the
> place where HBAC rule with time rules would need to be applied. We need
> to define the way we handle all these (unavailable, non-parsable and
> other kinds of errors) timezone info issues.

I would rather punt, than do some crappy thing ala Windows.

Local Only or UTC only is always wrong.

For some tasks 'local' is the only thing that makes sense (your morning
alarm clock), for other things 'UTC' is the only thing that make sense
(coordinated changes across multiple distributed data centers).

Implementing just one or the other is not useful.

-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Simo Sorce]

On Mon, 2015-03-09 at 18:13 +0100, Jakub Hrozek wrote:
> On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
> > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> > > On Mon, 09 Mar 2015, Martin Kosek wrote:
> > ...
> > > One of bigger issues we had was lack of versatile ical format parser to
> > > handle calendar-like specification of events -- we need to allow
> > > importing these ones instead of inventing our own.
> > 
> > Good point. I wonder how rigorous we want to be. iCal is a pretty powerful
> > calendaring format. If we want to implement full support for it, it would be
> > lot of code both on server side for setting it and on client side for
> > evaluating it (CCing Jakub for reference).
> > 
> > AD itself has much simpler UI for setting the access time, a table like 
> > that:
> > http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
> > 
> > IIRC, they only store the bits of "can login/cannot login" for the time 
> > slots.
> > That's another alternative.
> 
> I don't think that's what Alexander meant, I don't think the client
> library should come anywhere close to the iCal format. We might want to
> provide a script to convert an external format, but that's about it.
> 
> I thought we could simply reuse parts of the previous grammar, maybe
> simplified. But I agree with Nathaniel (as I stated also in the private
> thread) that we should use UTC where possible.

Simplified == Kinda Broken.

We've been through this a few times already, it just doesn't work.
At a minimum you need to be able to select between UTC and "Local Time"
and it is a rathole down there (What time is it *here* may be a hard
question to answer :-/)

> > 
> > > Another issue is that often rule does depend on a details about specific
> > > service -- it is common to have web services to use different timezone
> > > than the rest of processes running on the server. You would get an HBAC
> > > rule where something like apache service is defined but you'd need to
> > > associate timezone with it and have this association to be specific to a
> > > server or group of servers rather than just a service itself.
> > 
> > HBAC service is mostly only PAM service, not IPA service, so I do not think 
> > you
> > can easily store this information. But we can certainly store time zone
> > information in a host or a host group and let that help the hbactest-* or 
> > UI...
> 


-- 
Simo Sorce * Red Hat, Inc * New York

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Mon, 09 Mar 2015, Nathaniel McCallum wrote:

On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote:

On Mon, 09 Mar 2015, Jakub Hrozek wrote:
> On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
> > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> > > On Mon, 09 Mar 2015, Martin Kosek wrote:
> > ...
> > > One of bigger issues we had was lack of versatile ical format
> > > parser to handle calendar-like specification of events -- we
> > > need to allow importing these ones instead of inventing our
> > > own.
> >
> > Good point. I wonder how rigorous we want to be. iCal is a
> > pretty powerful
> > calendaring format. If we want to implement full support for it,
> > it would be
> > lot of code both on server side for setting it and on client
> > side for evaluating it (CCing Jakub for reference).
> >
> > AD itself has much simpler UI for setting the access time, a
> > table like that:
> > 
http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
> >
> > IIRC, they only store the bits of "can login/cannot login" for
> > the time slots.
> > That's another alternative.
>
> I don't think that's what Alexander meant, I don't think the
> client library should come anywhere close to the iCal format. We
> might want to provide a script to convert an external format, but
> that's about it.
>
> I thought we could simply reuse parts of the previous grammar,
> maybe simplified. But I agree with Nathaniel (as I stated also in
> the private thread) that we should use UTC where possible.
Yes and no. Let me go in details a bit.

We need iCal support to allow importing events created by external
tools. We don't need to use it as internal format.

However, there are quite a lot of details that can be lost if only
UTC would be in use for a date as you are ignoring a timezone
information completely. Timezone information needs to be kept when
importing and not always could be reliably represented in UTC so
that conversion from one timezone to another could present quite a
problem.

See  http://www.w3.org/TR/timezone/for some of recommendations.


I'm fine with a plan like this. I just want the admin to opt-in to
timezones. Localtime *by default* is fraught with pitfalls. If the
admin needs local time policy, he should specify it exactly and should
confirm the local time on affected systems.

Yep. We need to make it easy -- probably by allowing to define timezones
as part of host object (like Martin proposed) and overridden in HBAC
service/service group. And all this have to be very visual in the UI.

Another problem is how to deal with missing timezone information at the
place where HBAC rule with time rules would need to be applied. We need
to define the way we handle all these (unavailable, non-parsable and
other kinds of errors) timezone info issues.
--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Nathaniel McCallum]

On Mon, 2015-03-09 at 20:22 +0200, Alexander Bokovoy wrote:
> On Mon, 09 Mar 2015, Jakub Hrozek wrote:
> > On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
> > > On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> > > > On Mon, 09 Mar 2015, Martin Kosek wrote:
> > > ...
> > > > One of bigger issues we had was lack of versatile ical format 
> > > > parser to handle calendar-like specification of events -- we 
> > > > need to allow importing these ones instead of inventing our 
> > > > own.
> > > 
> > > Good point. I wonder how rigorous we want to be. iCal is a 
> > > pretty powerful
> > > calendaring format. If we want to implement full support for it, 
> > > it would be
> > > lot of code both on server side for setting it and on client 
> > > side for evaluating it (CCing Jakub for reference).
> > > 
> > > AD itself has much simpler UI for setting the access time, a 
> > > table like that:
> > > http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
> > > 
> > > IIRC, they only store the bits of "can login/cannot login" for 
> > > the time slots.
> > > That's another alternative.
> > 
> > I don't think that's what Alexander meant, I don't think the 
> > client library should come anywhere close to the iCal format. We 
> > might want to provide a script to convert an external format, but 
> > that's about it.
> > 
> > I thought we could simply reuse parts of the previous grammar, 
> > maybe simplified. But I agree with Nathaniel (as I stated also in 
> > the private thread) that we should use UTC where possible.
> Yes and no. Let me go in details a bit.
> 
> We need iCal support to allow importing events created by external 
> tools. We don't need to use it as internal format.
> 
> However, there are quite a lot of details that can be lost if only 
> UTC would be in use for a date as you are ignoring a timezone 
> information completely. Timezone information needs to be kept when 
> importing and not always could be reliably represented in UTC so 
> that conversion from one timezone to another could present quite a 
> problem.
> 
> See  http://www.w3.org/TR/timezone/for some of recommendations.

I'm fine with a plan like this. I just want the admin to opt-in to 
timezones. Localtime *by default* is fraught with pitfalls. If the 
admin needs local time policy, he should specify it exactly and should 
confirm the local time on affected systems.

Nathaniel

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Mon, 09 Mar 2015, Jakub Hrozek wrote:

On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:

On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> On Mon, 09 Mar 2015, Martin Kosek wrote:
...
> One of bigger issues we had was lack of versatile ical format parser to
> handle calendar-like specification of events -- we need to allow
> importing these ones instead of inventing our own.

Good point. I wonder how rigorous we want to be. iCal is a pretty powerful
calendaring format. If we want to implement full support for it, it would be
lot of code both on server side for setting it and on client side for
evaluating it (CCing Jakub for reference).

AD itself has much simpler UI for setting the access time, a table like that:
http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg

IIRC, they only store the bits of "can login/cannot login" for the time slots.
That's another alternative.


I don't think that's what Alexander meant, I don't think the client
library should come anywhere close to the iCal format. We might want to
provide a script to convert an external format, but that's about it.

I thought we could simply reuse parts of the previous grammar, maybe
simplified. But I agree with Nathaniel (as I stated also in the private
thread) that we should use UTC where possible.

Yes and no. Let me go in details a bit.

We need iCal support to allow importing events created by external
tools. We don't need to use it as internal format.

However, there are quite a lot of details that can be lost if only UTC
would be in use for a date as you are ignoring a timezone information
completely. Timezone information needs to be kept when importing and not
always could be reliably represented in UTC so that conversion from one
timezone to another could present quite a problem.

See http://www.w3.org/TR/timezone/ for some of recommendations.


--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Jakub Hrozek]

On Mon, Mar 09, 2015 at 04:08:46PM +0100, Martin Kosek wrote:
> On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> > On Mon, 09 Mar 2015, Martin Kosek wrote:
> ...
> > One of bigger issues we had was lack of versatile ical format parser to
> > handle calendar-like specification of events -- we need to allow
> > importing these ones instead of inventing our own.
> 
> Good point. I wonder how rigorous we want to be. iCal is a pretty powerful
> calendaring format. If we want to implement full support for it, it would be
> lot of code both on server side for setting it and on client side for
> evaluating it (CCing Jakub for reference).
> 
> AD itself has much simpler UI for setting the access time, a table like that:
> http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg
> 
> IIRC, they only store the bits of "can login/cannot login" for the time slots.
> That's another alternative.

I don't think that's what Alexander meant, I don't think the client
library should come anywhere close to the iCal format. We might want to
provide a script to convert an external format, but that's about it.

I thought we could simply reuse parts of the previous grammar, maybe
simplified. But I agree with Nathaniel (as I stated also in the private
thread) that we should use UTC where possible.

> 
> > Another issue is that often rule does depend on a details about specific
> > service -- it is common to have web services to use different timezone
> > than the rest of processes running on the server. You would get an HBAC
> > rule where something like apache service is defined but you'd need to
> > associate timezone with it and have this association to be specific to a
> > server or group of servers rather than just a service itself.
> 
> HBAC service is mostly only PAM service, not IPA service, so I do not think 
> you
> can easily store this information. But we can certainly store time zone
> information in a host or a host group and let that help the hbactest-* or 
> UI...

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Mon, 09 Mar 2015, Martin Kosek wrote:

On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:

On Mon, 09 Mar 2015, Martin Kosek wrote:

...

One of bigger issues we had was lack of versatile ical format parser to
handle calendar-like specification of events -- we need to allow
importing these ones instead of inventing our own.


Good point. I wonder how rigorous we want to be. iCal is a pretty powerful
calendaring format. If we want to implement full support for it, it would be
lot of code both on server side for setting it and on client side for
evaluating it (CCing Jakub for reference).

AD itself has much simpler UI for setting the access time, a table like that:
http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg

IIRC, they only store the bits of "can login/cannot login" for the time slots.
That's another alternative.


Another issue is that often rule does depend on a details about specific
service -- it is common to have web services to use different timezone
than the rest of processes running on the server. You would get an HBAC
rule where something like apache service is defined but you'd need to
associate timezone with it and have this association to be specific to a
server or group of servers rather than just a service itself.


HBAC service is mostly only PAM service, not IPA service, so I do not think you
can easily store this information. But we can certainly store time zone
information in a host or a host group and let that help the hbactest-* or UI...

I don't understand why are you involving IPA services here. HBAC rules
are only about PAM services and PAM (HBAC) services are specific to
hosts where they are in use. We aren't *that* contextual yet because
we didn't need that in past but having a timezone info only per host is
wrong precisely because every single process on the host can be run
under different timezone as it is just a way of interpreting monotone
time source data we get from kernel.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/09/2015 03:58 PM, Alexander Bokovoy wrote:
> On Mon, 09 Mar 2015, Martin Kosek wrote:
...
> One of bigger issues we had was lack of versatile ical format parser to
> handle calendar-like specification of events -- we need to allow
> importing these ones instead of inventing our own.

Good point. I wonder how rigorous we want to be. iCal is a pretty powerful
calendaring format. If we want to implement full support for it, it would be
lot of code both on server side for setting it and on client side for
evaluating it (CCing Jakub for reference).

AD itself has much simpler UI for setting the access time, a table like that:
http://www.intelliadmin.com/images/Logon%20Hours%20Windows%20Active%20Directory.jpg

IIRC, they only store the bits of "can login/cannot login" for the time slots.
That's another alternative.

> Another issue is that often rule does depend on a details about specific
> service -- it is common to have web services to use different timezone
> than the rest of processes running on the server. You would get an HBAC
> rule where something like apache service is defined but you'd need to
> associate timezone with it and have this association to be specific to a
> server or group of servers rather than just a service itself.

HBAC service is mostly only PAM service, not IPA service, so I do not think you
can easily store this information. But we can certainly store time zone
information in a host or a host group and let that help the hbactest-* or UI...

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Alexander Bokovoy]

On Mon, 09 Mar 2015, Martin Kosek wrote:

On 03/09/2015 02:02 PM, Nathaniel McCallum wrote:

On Mon, 2015-03-09 at 08:00 +0100, Stanislav Láznička wrote:

Hi!

My name is Stanislav Laznicka and I am a student at Brno University
of Technology. As a part of my Master's thesis, I am supposed to
design and
implement time-based account policies extensions for FreeIPA and
SSSD.

While going through the code, I noticed time-based access control
was implemented in the past, but it was pulled. I would very much be
interested to know why that was and what were the problems with that
implementation (so that I don't repeat those again).

The solution to the time-based account policies as I see it can be
divided into two possible directions - having the time of the
policies stored as a UTC time (which is what both Active Directory
and 389 Directory Server do), or it can be just a time record that
would be compared to the local time of each client.

Each of the approaches above has its pros and cons. Basically, local
time approach is much more flexible when it comes to multiple time
zones, however it does not allow the absolute control of access as
the UTC time based approach would (or at least, it does not allow it
without
some further additions). I would therefore also be interested to
hear from you about which of these approaches corresponds more to
the common use-case of the FreeIPA system.


I would be deeply worried about the unexpected security issues that
could arise if local time was used by default.

Nathaniel


My comments for the options:

* Control in UTC time: easy to evaluate on client even when user (or anyone
else) misconfigured the time zone. However, implementation is more difficult:
 - For rules like "person X can interactively log in from 8:00 to 17:00", you
would need separate HBAC rule for each time zone as UTC range would differ

HBAC rules are applied on the client anyway so applying local time
correction is fine in both cases. The problem is then with HBAC rule
testing ('ipa hbactest') which runs on IPA master and would need to gain
ability to handle local time per client too. And this is not an easy
task.


 - On the other hand, one can create simple rule "person X can use company
resources from 8:00 EST to 17:00 EST, in whichever time zone they are located)
 - FreeIPA would need some helper UI (or even zone indication stored with
host/hostgroup) that would help set up the access in local time and save in UTC
time

UI/CLI helpers are smaller issue if we can agree on the basic
functionality.

One of bigger issues we had was lack of versatile ical format parser to
handle calendar-like specification of events -- we need to allow
importing these ones instead of inventing our own.

Another issue is that often rule does depend on a details about specific
service -- it is common to have web services to use different timezone
than the rest of processes running on the server. You would get an HBAC
rule where something like apache service is defined but you'd need to
associate timezone with it and have this association to be specific to a
server or group of servers rather than just a service itself.

--
/ Alexander Bokovoy

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Martin Kosek]

On 03/09/2015 02:02 PM, Nathaniel McCallum wrote:
> On Mon, 2015-03-09 at 08:00 +0100, Stanislav Láznička wrote:
>> Hi!
>>
>> My name is Stanislav Laznicka and I am a student at Brno University 
>> of Technology. As a part of my Master's thesis, I am supposed to 
>> design and
>> implement time-based account policies extensions for FreeIPA and 
>> SSSD.
>>
>> While going through the code, I noticed time-based access control 
>> was implemented in the past, but it was pulled. I would very much be 
>> interested to know why that was and what were the problems with that 
>> implementation (so that I don't repeat those again).
>>
>> The solution to the time-based account policies as I see it can be 
>> divided into two possible directions - having the time of the 
>> policies stored as a UTC time (which is what both Active Directory 
>> and 389 Directory Server do), or it can be just a time record that 
>> would be compared to the local time of each client.
>>
>> Each of the approaches above has its pros and cons. Basically, local 
>> time approach is much more flexible when it comes to multiple time 
>> zones, however it does not allow the absolute control of access as 
>> the UTC time based approach would (or at least, it does not allow it 
>> without
>> some further additions). I would therefore also be interested to 
>> hear from you about which of these approaches corresponds more to 
>> the common use-case of the FreeIPA system.
> 
> I would be deeply worried about the unexpected security issues that 
> could arise if local time was used by default.
> 
> Nathaniel

My comments for the options:

* Control in UTC time: easy to evaluate on client even when user (or anyone
else) misconfigured the time zone. However, implementation is more difficult:
  - For rules like "person X can interactively log in from 8:00 to 17:00", you
would need separate HBAC rule for each time zone as UTC range would differ
  - On the other hand, one can create simple rule "person X can use company
resources from 8:00 EST to 17:00 EST, in whichever time zone they are located)
  - FreeIPA would need some helper UI (or even zone indication stored with
host/hostgroup) that would help set up the access in local time and save in UTC
time

* Control in local time: difficult to evaluate, potential security issues as
Nathaniel mentioned. Implementation and control would be easier though:
  - One could set up easy rule: "person X can interactivelly log in from 8:00
to 17:00"
  - Easier UI as one would not need to mess with zones, we would assume time
zone is set up correctly on each host.

So far, it indeed looks like UTC is the way to go.

Martin

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] Time-based account policies

[Nathaniel McCallum]

On Mon, 2015-03-09 at 08:00 +0100, Stanislav Láznička wrote:
> Hi!
> 
> My name is Stanislav Laznicka and I am a student at Brno University 
> of Technology. As a part of my Master's thesis, I am supposed to 
> design and
> implement time-based account policies extensions for FreeIPA and 
> SSSD.
> 
> While going through the code, I noticed time-based access control 
> was implemented in the past, but it was pulled. I would very much be 
> interested to know why that was and what were the problems with that 
> implementation (so that I don't repeat those again).
> 
> The solution to the time-based account policies as I see it can be 
> divided into two possible directions - having the time of the 
> policies stored as a UTC time (which is what both Active Directory 
> and 389 Directory Server do), or it can be just a time record that 
> would be compared to the local time of each client.
> 
> Each of the approaches above has its pros and cons. Basically, local 
> time approach is much more flexible when it comes to multiple time 
> zones, however it does not allow the absolute control of access as 
> the UTC time based approach would (or at least, it does not allow it 
> without
> some further additions). I would therefore also be interested to 
> hear from you about which of these approaches corresponds more to 
> the common use-case of the FreeIPA system.

I would be deeply worried about the unexpected security issues that 
could arise if local time was used by default.

Nathaniel

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

[Freeipa-devel] Time-based account policies

[Stanislav Láznička]

Hi!

My name is Stanislav Laznicka and I am a student at Brno University of 
Technology. As a part of my Master's thesis, I am supposed to design and 
implement time-based account policies extensions for FreeIPA and SSSD.


While going through the code, I noticed time-based access control was 
implemented in the past, but it was pulled. I would very much be 
interested to know why that was and what were the problems with that 
implementation (so that I don't repeat those again).


The solution to the time-based account policies as I see it can be 
divided into two possible directions - having the time of the policies 
stored as a UTC time (which is what both Active Directory and 389 
Directory Server do), or it can be just a time record that would be 
compared to the local time of each client.


Each of the approaches above has its pros and cons. Basically, local 
time approach is much more flexible when it comes to multiple time 
zones, however it does not allow the absolute control of access as the 
UTC time based approach would (or at least, it does not allow it without 
some further additions). I would therefore also be interested to hear 
from you about which of these approaches corresponds more to the common 
use-case of the FreeIPA system.


Cheers,
Standa L.

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code