[Freeipa-devel] Time-based account policies

Martin Kosek mkosek at redhat.com
Tue Mar 10 14:47:10 UTC 2015


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




More information about the Freeipa-devel mailing list