On 07/15/2016 03:11 PM, Simo Sorce wrote:
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...@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...@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.
Those two files show two different implementations - templates.ldif of
the template approach, objects.ldif of "time rules as objects" approach.
Should have probably mentioned that. Also, like I said, I should have
probably included "accessTime" in the objects.ldif ipaHBACRulev2, which
I believe is the only difference there that does not have to do anything
with how this works.
"accessTime" is an attributeType defined in some IPA 2.0 version or so
which should bear the time policy information. Each of the time rules
objects should bear one single-valued "accessTime" attribute.
"accessTime" is originally defined as multi-valued so we may want to
have a new attribute defined for that use.
Time rules would have their own container somewhere in LDAP, currently
working with it being in the realm tree. There, you would add the time
rule objects - objects with a name and the information of when such rule
would apply. These you would be able to add as members to an HBAC rule.
With templates, it's very similar, except that you are able to
rewrite/set the accessTime attribute value directly at the HBAC rule
object (as nothing is actually stored there because CoSTemplates), thus
saving the string directly within the HBAC rule object. This, however,
makes it very hard for the time rules to be worked with as you basically
lose the information about which of the time rules you want to change in
that multivalued HBAC attribute as you can probably imagine.
As for how the time policy string is stored - it's an iCalendar string.
Is it more clear now? I don't currently have ldifs of any interesting
use of either approach.
Standa
--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code
