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
> sensitive piece for authorization rules.
> We may need to use libraries for processing iCal rules, like libical
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
Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code