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

Wed Nov 11 14:30:53 UTC 2015

On 11.11.2015 14:52, Martin Basti wrote:
> 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.
After IRC discussion with pspacek and jcholast:

We should just create separated privileges to time rules and allow them 
to be shared.
So they should be stored in new container in LDAP

Martin^2
>
>> 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/9418c901/attachment.htm>