[Freeipa-devel] [Update]Time-Based Account Policies

Wed Nov 11 13:52:52 UTC 2015

Comments inline
Martin^2

On 11.11.2015 09:24, Stanislav Laznicka wrote:
> On 11/05/2015 06:17 PM, Petr Spacek wrote:
>> On 4.11.2015 15:20, Martin Basti wrote:
>>
>>> Hello,
>>>
>>> we (Standa and I) had offline discussion and I proposed following idea:
>>>
>>> 1) create new entry in LDAP for "time rule" instead of adding the time rule
>>> string directly into HBACRule.
>>> This will allow to reuse time rules among various HBAC Rules (and maybe in
>>> future with sudo rules, etc.)
>>> HBACrule gets only reference to time rule entry stored in LDAP db.
>> Good idea! I can see time rule entry 'working hours in Brno office' which is
>> linked to relevant HBAC rules.
> This seems like a good idea. However, it might be a bit messy to have 
> even the least significant rules stored in separate objects. But I 
> agree. It brings some questions, though.
Imo to have separate entry for time rule is cleaner than add it directly 
to HBAC rule.

> Where would be a good spot to store these time rules?
As I originally thought that we can share time rules between HBAC, SUDO 
and everything else, I couldn't be wrong more.

Example: HBAC admin have permission to edit HBAC rule, but doesn't have 
permission to edit SUDO rule. The HBAC admin should be able to edit time 
rules for HBAC rules, and cannot be able to edit time rules of SUDO 
rules. Thus time rules must be separated between HBAC, SUDO and others, 
and privilege that give the permission to modify HBAC rule, must give 
permission to modify only HBAC time rules.

I suggest to add HBAC time rules to HBAC container.

> Should they be able to form groups?
I think to allow multiple time rules per HBAC rule is enough.
> Should such an object be able to hold more time policies strings and 
> exceptions, as it does now, or would it be better to set that in the 
> respective HBAC rule?
Can it be one time policy per entry? Do you expect that users may need a 
many complicated rules?
Generally to have an object time policy that consist of time rule 
objects which are in fact the iCal string is good idea, but is it worth 
it? We should not overengineering it.
>>
>>> 2) Do not create a new time format, just reuse iCal (parts of iCal we need),
>>> to store time rule in LDAP in "time rule" entry
>>> (Or is possible to not store the values just as one string, we can use
>>> different attributes to store separate values, iCal can be used as export and
>>> import format)
>> I very much agree with re-using iCal! We have sufficient number of custom
>> parsers already ;-)
>>
>> Speaking about custom LDAP format, I do not think that it is a good idea. It
>> would prevent us from using iCal parsers and generators and we would risk that
>> our custom LDAP format will not be flexible enough.
>>
>> For these reasons I would go with 1 iCal string which can be fed into any
>> standard-compliant iCal library.
> I was thinking long and hard about actually using the iCalendar format 
> for this purpose, ever since the 'repeat' keyword was supposed to be 
> included in the language. However, as I mentioned some time ago, the 
> iCalendar format recurrences are OK when it comes to recurring events 
> but I am not sure about them being very suitable for describing time 
> policies.
>
> Let me do a comparison of the options. I will take in question only 
> the RRULE (and possibly PERIOD) part of the iCalendar format. Having 
> the whole iCalendar format involved along with its parsing C library 
> seemed to be a no-go for SSSD some 6 months ago and I can imagine such 
> feelings persist.
>
> ----------------------------
> Some iCalendar cons:
>
> 1) It is hard to represent continuous time of a day ranges
> There does not seem to be an easy equivalent to e.g. 'timeofday= 
> 0730~1100, 1200~1615'. The easiest way to do this in iCalendar would 
> be to have 2 rules of the form:
>
> DTSTART: 19700101T073000
> DTEND: 19700101T110000
> RRULE: FREQ=DAILY; INTERVAL=1
>
> DTSTART: 19700101T120000
> DTEND: 19700101T161500
> RRULE: FREQ=DAILY; INTERVAL=1
>
> If you were setting some more difficult policy, there would have to be 
> a lot of duplicity in each of such rules.
Is this common usage? I personally cannot imagine reason to using more 
than max 2 time periods per day.
>
> 2) All iCalendar events have to have a fixed starting point
> There must always be a check against the interval and the starting point.
MIN, or date of creation can be used as default
>
> 3) There are no ranges
> e.g. 'dayofyear=2-50, 100-125' would translate to
>
> DTSTART:19700101T000000
> RRULE: FREQ=SECONDLY; INTERVAL=1; 
> BYYEARDAY=2,3,4,5,6,7,8,9,10,11,...50,100,101,102,...

>
> 4) There is no way to list specific years in which the HBAC rule 
> should apply.
is this a real concern?
>
> 5) COUNT parameter makes you generate all previous events before you 
> are able to tell if the current one actually applies.
> Imagine COUNT being a big number and an event that hardly ever 
> happens. Imagine current time to fall into the last event.
If we want to have the iCal support, we must live with this, but we can 
force user to use end date in CLI/webUI (in other words disable COUNT as 
option in CLI/webUI)
>
> 6) The event descriptions are not so intuitive
> There would probably have to be better conversion system at least for 
> CLI when user wants to set time ranges of access allowed times so that 
> we can consider it good UX.
>
UX is in our hands
> I am not mentioning the lack of weekofmonth in iCal as I would rather 
> drop it from the current solution, too.
> ----------------------------
> On the other hand, there are also some big pros for iCalendar.
>
> 1) It is a standard. It behaves in a known and described manner.
> 2)  By proper use of BYSETPOS of RRULE, it is able to describe some 
> specific situations, e.g. last workday of a month. This is not 
> possible in the current language.
> 3) Easier setting of absolute time ranges using the PERIOD property 
> (although this could probably be easily solved by a minor addition to 
> the current solution).
> 4) A GUI for setting RRULEs already exists.
>
> ad 4) The GUI, however, hides some of the features of the language 
> (e.g. the mentioned BYSETPOS) and is not suitable for setting time 
> policies as is. Try, for example, setting a policy "allow access from 
> 7:00 to 16:00 (no break of the interval as iCalendar does not know it) 
> every first Monday through Friday of a month for the first half of 
> every year".
>
> In current language:
>
> timeofday=0700~1600 dayofmonth=1~7 dayofweek=1~5 monthofyear=1~6
>
> In iCalendar RRULE:
>
> DTSTART: 19700101T070000
> DTEND: 19700101T160000
> RRULE: FREQ=YEARLY; BYMONTH=1,2,3,4,5,6;BYDAY=1MO,1TU,1WE,1TH,1FR
> ----------------------------
>
> Hopefully, this was a thorough walk-through of the pros and cons of 
> both approaches. I believe I stayed clear of any sentiment to the work 
> I did of which a big part could come in vain if we moved to iCalendar 
> format. Please correct me if I haven't.
IMO most of examples above are overkill and we only should solve in 
CLI/webUI how to easily add the time rules that are the most used.
If somebody needs a something special, the one is allowed to import the 
own time rule in the iCal format.
>
> I wonder if we want to have someone from SSSD in this discussion, too.
>>
>>> 3) We may provide nice CLI and webUI to construct/show "time rule", this may
>>> be more user friendly than just passing the string containing time data to
>>> HBAC rule.
>> This is going to be the same as in any calendaring system. Just look to
>> Thunderbird "New Event" dialog.
>>
> Please, see my comments on the GUI in ad 4). On the other hand to the 
> comments - there is at least something done in iCalendar GUI that we 
> could use rather than coining out a whole new GUI for time policies.
>
> --
> Standa

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20151111/63347056/attachment.htm>