[Freeipa-devel] [DESIGN] Time-Based HBAC Policies

[Simo Sorce]

On Fri, 2016-07-15 at 14:29 +0200, Stanislav Laznicka wrote:
> On 07/15/2016 02:10 PM, Simo Sorce wrote:
> > 
> > On Wed, 2016-05-18 at 15:28 +0200, Stanislav Laznicka wrote:
> > > 
> > > On 05/18/2016 02:19 PM, Alexander Bokovoy wrote:
> > > > 
> > > > On Wed, 18 May 2016, Stanislav Laznicka wrote:
> > > > > 
> > > > > > 
> > > > > > > 
> > > > > > > when removal succeeds but addition fails for some reason?
> > > > > > > The
> > > > > > > operation is not atomic anymore.
> > > > > > > 
> > > > > We offline-discussed this with Honza. There should be a new
> > > > > command
> > > > > `ipa hbacrule-replace-accesstime rule_name --orig-
> > > > > time=icalstr1
> > > > > --new-time=icalstr2`. As it would be derived from LDAPQuery,
> > > > > the
> > > > > atomicity is kept. This may not be very nice for CLI but
> > > > > should
> > > > > work
> > > > > well for WebUI. Both icalstr1 and icalstr2 need to be encoded
> > > > > as
> > > > > newlines that appear so often in iCalendar strings would only
> > > > > make a
> > > > > mess here.
> > > > > 
> > > > > Example of use:
> > > > > 
> > > > > ipa hbacrule-replace-accesstime rule_name
> > > > > --orig-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The
> > > > > Company//iCal4j
> > > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVEN
> > > > > T\\r
> > > > > \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTA
> > > > > RT:2
> > > > > 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=M
> > > > > ONTH
> > > > > LY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VC
> > > > > ALEN
> > > > > DAR\\r\\n'"
> > > > > --new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The
> > > > > Company//iCal4j
> > > > > 1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVEN
> > > > > T\\r
> > > > > \\nUID:1 at company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTA
> > > > > RT:2
> > > > > 0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=M
> > > > > ONTH
> > > > > LY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND
> > > > > :VCA
> > > > > LENDAR\\r\\n'"
> > > > > 
> > > > > 
> > > > > to add Tuesdays to the timespan defined by the rule.
> > > > I would really like to see a file input support here. It would
> > > > be
> > > > simpler to operate in CLI as you would anyway create vCal files
> > > > --
> > > > no
> > > > sane person is going to deal with these strings directly on the
> > > > command
> > > > line.
> > > > 
> > > That is correct and some basic file support is already in the
> > > patches
> > > I
> > > sent earlier, though replacing rules is not a part of it.
> > > However,
> > > it
> > > does not solve the problem as you would still need access to the
> > > files
> > > to work with the attributes and then change the files
> > > accordingly.
> > > 
> > > However, we've had yet another brainstorm with Petr^2, Martin^2
> > > and
> > > Honza. We really don't want the above so we came up with some
> > > ideas
> > > that
> > > I'm listing below. Note that we also do not want more than one
> > > VEVENT
> > > component in any of the time rules. So, the ideas:
> > >       1) Have the time rules as separate objects. This approach
> > > got
> > > most
> > > support here. Adding Simo and Jakub to CC should they have any
> > > input
> > > against this.
> > >       2) Have the time rules stored as strings in the multi-
> > > valued
> > > accesstime attribute at each rule. These would be referenced by
> > > their
> > > UID property of the VEVENT component of the iCalendar string
> > > (instead
> > > of
> > > that pure hell above). As each of the strings can only contain
> > > one
> > > VEVENT which has to define a UID, the only problem would be to
> > > keep
> > > the
> > > uniqueness of UIDs consistent.
> > > 
> > >   From my point of view, 1) seems rather better but your
> > > experience
> > > might
> > > be different. Don't hesitate to share your opinions, please.
> > Can you please give me an example ldif of a complete hbac rule
> > including time rules with the 2 different proposals ?
> > 
> > I do not really care a lot how the framework ends up managing the
> > objetcs, I care mostly about how the information is stored in LDAP
> > and
> > how efficient the storage will be for SSSD retrieval.
> > 
> > That's my evaluation pov.
> > Keep in mind that rules are modified rarely but downloaded much
> > more
> > frequently, so it is ok to have a slightly harder way to store them
> > to
> > gain efficiency in retrieving and downloading them.
> > 
> > Simo.
> Please find the ldif files attached, with some additional changes
> than 
> only to hbac rules. It's from my current implementations.
> 
> OT: We had an offline discussion with Honza that to keep the
> backward 
> compatibility, it might be good to introduce v2 of HBAC rules so
> that's 
> what you see there. Perhaps accessTime should be in that v2 rule as
> well 
> but that's even more off-topic here.

I really would like an example ldif of a set of objects created with an
actual time rule in effect, the schema tells me something but not all.

You have ipaHBACRulev2 defined twice in different way in the two files,
why ?

What is accessTime ?

Simo.