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:VEVENT\\r
\\nUID:1...@company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:2
0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTH
LY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALEN
DAR\\r\\n'"
--new-time="'BEGIN:VCALENDAR\\r\\nPRODID:-//The Company//iCal4j
1.0//EN\\r\\nVERSION:2.0\\r\\nMETHOD:REQUEST\\r\\nBEGIN:VEVENT\\r
\\nUID:1...@company.org\\r\\nDTSTAMP:20160406T112129Z\\r\\nDTSTART:2
0101115T050000Z\\r\\nDTEND:20101115T070000Z\\r\\nRRULE:FREQ=MONTH
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.

objectClasses: (2.16.840.1.113730.3.8.4.80 NAME 'ipaTimeRule' SUP top STRUCTURAL MUST ( cn ) MAY ( memberOf $ accessTime ) X-ORIGIN 'IPA v4.5')
attributeTypes: (2.16.840.1.113730.3.8.4.72 NAME 'memberTimeRule' DESC 'Reference to a time rule describing some period of time' SUP distinguishedName EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 X-ORIGIN 'IPA v4.5' )
objectClasses: (2.16.840.1.113730.3.8.4.16 NAME 'ipaHBACRulev2' SUP ipaAssociation STRUCTURAL MUST accessRuleType MAY ( sourceHost $ sourceHostCategory $ serviceCategory $ memberService $ externalHost $ accessTime $ memberTimeRule ) X-ORIGIN 'IPA v4.5' )

dn: cn=timerules,$SUFFIX
changetype: add
objectClass: top
objectClass: nsContainer
cn: timerules

attributeTypes: (2.16.840.1.113730.3.8.11.72 NAME 'timeruleTemplate' DESC 'CNs of the timerule templates' EQUALITY caseIgnoreMatch ORDERING caseIgnoreOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'IPA v4.3' )
objectClasses: (2.16.840.1.113730.3.8.4.7 NAME 'ipaHBACRulev2' SUP ipaAssociation STRUCTURAL MUST accessRuleType MAY ( sourceHost $ sourceHostCategory $ serviceCategory $ memberService $ externalHost $ timeruleTemplate ) X-ORIGIN 'IPA v4.5' )

dn: cn=timeruleTemplates,$SUFFIX
changetype: add
objectClass: top
objectClass: nsContainer
cn: timeruleTemplates

dn: cn=cosTimerulesDef,cn=hbac,$SUFFIX
changetype: add
objectClass: top
objectClass: ldapsubentry
objectClass: cosSuperDefinition
objectClass: cosClassicDefinition
cosTemplateDn: cn=timeruleTemplates,$SUFFIX
cosAttribute: accessTime default merge-schemes
cosSpecifier: timeruleTemplate

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

Reply via email to