Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
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 > > > > > 0101115T05Z\\r\\nDTEND:20101115T07Z\\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 > > > > > 0101115T05Z\\r\\nDTEND:20101115T07Z\\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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
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 0101115T05Z\\r\\nDTEND:20101115T07Z\\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 0101115T05Z\\r\\nDTEND:20101115T07Z\\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 $
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
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 > > > 0101115T05Z\\r\\nDTEND:20101115T07Z\\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 > > > 0101115T05Z\\r\\nDTEND:20101115T07Z\\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. -- 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On Wed, May 18, 2016 at 05:13:11PM +0300, Alexander Bokovoy wrote: > On Wed, 18 May 2016, 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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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. > I'm for time rules as separate objects too. Multi-valued accesstime > attributes would not work well because you cannot really address > attributes by UID. >From SSSD point of view, I'm fine. We download all the HBAC related objects (all that apply to that host) anyway. Just please plan on abstracting the IPA HBAC object from its representation in libipa_hbac. -- 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 18.05.2016 16:13, Alexander Bokovoy wrote: On Wed, 18 May 2016, 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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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. For sure we should support import of iCals, but we should have simple interface for creating simple iCal, such as from 13:00, to 15:00, on Mo, Tu and Fri. For extra special rules the one may use iCal generator somewhere. Martin^2 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. I'm for time rules as separate objects too. Multi-valued accesstime attributes would not work well because you cannot really address attributes by UID. -- 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On Wed, 18 May 2016, 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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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. I'm for time rules as separate objects too. Multi-valued accesstime attributes would not work well because you cannot really address attributes by UID. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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. 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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. -- / Alexander Bokovoy -- 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 05/18/2016 01:47 PM, Stanislav Laznicka wrote: On 05/18/2016 01:15 PM, Stanislav Laznicka wrote: On 05/18/2016 01:00 PM, Petr Spacek wrote: On 18.5.2016 12:52, Jan Cholasta wrote: On 18.5.2016 12:43, Stanislav Laznicka wrote: On 05/18/2016 12:38 PM, Jan Cholasta wrote: On 18.5.2016 12:23, Petr Spacek wrote: On 18.5.2016 08:25, Stanislav Laznicka wrote: On 05/17/2016 12:40 PM, Petr Spacek wrote: On 13.5.2016 13:50, Stanislav Laznicka wrote: Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? NACK, the dns plugin should not be used as an example for anything, as it breaks almost every convention in the framework. Good point :-) Also, typical iCalendar string is not much suitable for this approach (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your proposal is a way, of course, but not much user-friendly here. Removing and adding of particular accesstime values should be done by a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and "hbacrule-remove-accesstime rule_name accesstime". What about modifications, thought? If not for CLI, you will still need a way to modify a more complex time rule in the WebUI (you do not want to remove a complex rule just to click through its creation all again for a minor change). Modification of an attribute value is exactly that - the old value gets removed and the new value gets added. How it will look like in the web UI is a completely different thing. The question here is if the intermediate state without defined time (remember, no transactions!) is acceptable or not. Does it mean that the time restriction will removed OR that access will be always denied because the rule is incomplete? Pretty good point I was about to raise myself. Also, what happens 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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\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:20101115T05Z\\r\\nDTEND:20101115T07Z\\r\\nRRULE:FREQ=MONTHLY;INTERVAL=5;BYDAY=MO,TU;BYHOUR=5,6\\r\\nEND:VEVENT\\r\\nEND:VCALENDAR\\r\\n'" to add Tuesdays to the timespan defined by the rule. Currently, if the time is not set it means users are allowed in. That was there because of the backward compatibility although that could now be bent to our wills as it should be solved differently (see latest post of Lukas Hellebrandt on URI in HBAC and his ipahbacruleuri). Allow on empty accesstime behaviour should be kept. We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 18.05.2016 13:47, Stanislav Laznicka wrote: On 05/18/2016 01:15 PM, Stanislav Laznicka wrote: On 05/18/2016 01:00 PM, Petr Spacek wrote: On 18.5.2016 12:52, Jan Cholasta wrote: On 18.5.2016 12:43, Stanislav Laznicka wrote: On 05/18/2016 12:38 PM, Jan Cholasta wrote: On 18.5.2016 12:23, Petr Spacek wrote: On 18.5.2016 08:25, Stanislav Laznicka wrote: On 05/17/2016 12:40 PM, Petr Spacek wrote: On 13.5.2016 13:50, Stanislav Laznicka wrote: Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? NACK, the dns plugin should not be used as an example for anything, as it breaks almost every convention in the framework. Good point :-) Also, typical iCalendar string is not much suitable for this approach (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your proposal is a way, of course, but not much user-friendly here. Removing and adding of particular accesstime values should be done by a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and "hbacrule-remove-accesstime rule_name accesstime". What about modifications, thought? If not for CLI, you will still need a way to modify a more complex time rule in the WebUI (you do not want to remove a complex rule just to click through its creation all again for a minor change). Modification of an attribute value is exactly that - the old value gets removed and the new value gets added. How it will look like in the web UI is a completely different thing. The question here is if the intermediate state without defined time (remember, no transactions!) is acceptable or not. Does it mean that the time restriction will removed OR that access will be always denied because the rule is incomplete? Pretty good point I was about to raise myself. Also, what happens 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. But in this case, what is the benefit for user? putting ical there that looks like magic runes of mighty spell is not the best UX for me, in this case you will limit the usage of this feature only for webUI, nobody from mortals will be able to set time rule in nice way. In case you have just one time event in one timerule, you can use options like --start, --end, --in-days, etc for the particular time-rule name and you don't need to specify which part of ICAL string you are modifying because there is only one, and this one rule will be updated. Martin^2 Currently, if the time is not set it means users are allowed in. That was there because of the backward compatibility although that could now be bent to our wills as it should be solved differently (see latest post of Lukas Hellebrandt on URI in HBAC and his ipahbacruleuri). Allow on empty accesstime behaviour should be kept. We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original reasoning pro and against the proposed solution could be found on the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would be really nice to hear your opinions and ideas that could help us overcome this
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 05/18/2016 01:15 PM, Stanislav Laznicka wrote: On 05/18/2016 01:00 PM, Petr Spacek wrote: On 18.5.2016 12:52, Jan Cholasta wrote: On 18.5.2016 12:43, Stanislav Laznicka wrote: On 05/18/2016 12:38 PM, Jan Cholasta wrote: On 18.5.2016 12:23, Petr Spacek wrote: On 18.5.2016 08:25, Stanislav Laznicka wrote: On 05/17/2016 12:40 PM, Petr Spacek wrote: On 13.5.2016 13:50, Stanislav Laznicka wrote: Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? NACK, the dns plugin should not be used as an example for anything, as it breaks almost every convention in the framework. Good point :-) Also, typical iCalendar string is not much suitable for this approach (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your proposal is a way, of course, but not much user-friendly here. Removing and adding of particular accesstime values should be done by a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and "hbacrule-remove-accesstime rule_name accesstime". What about modifications, thought? If not for CLI, you will still need a way to modify a more complex time rule in the WebUI (you do not want to remove a complex rule just to click through its creation all again for a minor change). Modification of an attribute value is exactly that - the old value gets removed and the new value gets added. How it will look like in the web UI is a completely different thing. The question here is if the intermediate state without defined time (remember, no transactions!) is acceptable or not. Does it mean that the time restriction will removed OR that access will be always denied because the rule is incomplete? Pretty good point I was about to raise myself. Also, what happens 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. Currently, if the time is not set it means users are allowed in. That was there because of the backward compatibility although that could now be bent to our wills as it should be solved differently (see latest post of Lukas Hellebrandt on URI in HBAC and his ipahbacruleuri). Allow on empty accesstime behaviour should be kept. We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original reasoning pro and against the proposed solution could be found on the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would be really nice to hear your opinions and ideas that could help us overcome this problem. Thank you, 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 18.5.2016 13:00, Petr Spacek wrote: On 18.5.2016 12:52, Jan Cholasta wrote: On 18.5.2016 12:43, Stanislav Laznicka wrote: On 05/18/2016 12:38 PM, Jan Cholasta wrote: On 18.5.2016 12:23, Petr Spacek wrote: On 18.5.2016 08:25, Stanislav Laznicka wrote: On 05/17/2016 12:40 PM, Petr Spacek wrote: On 13.5.2016 13:50, Stanislav Laznicka wrote: Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? NACK, the dns plugin should not be used as an example for anything, as it breaks almost every convention in the framework. Good point :-) Also, typical iCalendar string is not much suitable for this approach (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your proposal is a way, of course, but not much user-friendly here. Removing and adding of particular accesstime values should be done by a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and "hbacrule-remove-accesstime rule_name accesstime". What about modifications, thought? If not for CLI, you will still need a way to modify a more complex time rule in the WebUI (you do not want to remove a complex rule just to click through its creation all again for a minor change). Modification of an attribute value is exactly that - the old value gets removed and the new value gets added. How it will look like in the web UI is a completely different thing. The question here is if the intermediate state without defined time (remember, no transactions!) is acceptable or not. Does it mean that the time restriction will removed OR that access will be always denied because the rule is incomplete? I certainly hope that this will be implemented in such a way that it's the latter :-) Petr^2 Spacek We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original reasoning pro and against the proposed solution could be found on the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would be really nice to hear your opinions and ideas that could help us overcome this problem. Thank you, Standa -- Jan Cholasta -- 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 05/18/2016 01:00 PM, Petr Spacek wrote: On 18.5.2016 12:52, Jan Cholasta wrote: On 18.5.2016 12:43, Stanislav Laznicka wrote: On 05/18/2016 12:38 PM, Jan Cholasta wrote: On 18.5.2016 12:23, Petr Spacek wrote: On 18.5.2016 08:25, Stanislav Laznicka wrote: On 05/17/2016 12:40 PM, Petr Spacek wrote: On 13.5.2016 13:50, Stanislav Laznicka wrote: Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? NACK, the dns plugin should not be used as an example for anything, as it breaks almost every convention in the framework. Good point :-) Also, typical iCalendar string is not much suitable for this approach (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your proposal is a way, of course, but not much user-friendly here. Removing and adding of particular accesstime values should be done by a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and "hbacrule-remove-accesstime rule_name accesstime". What about modifications, thought? If not for CLI, you will still need a way to modify a more complex time rule in the WebUI (you do not want to remove a complex rule just to click through its creation all again for a minor change). Modification of an attribute value is exactly that - the old value gets removed and the new value gets added. How it will look like in the web UI is a completely different thing. The question here is if the intermediate state without defined time (remember, no transactions!) is acceptable or not. Does it mean that the time restriction will removed OR that access will be always denied because the rule is incomplete? Pretty good point I was about to raise myself. Also, what happens when removal succeeds but addition fails for some reason? The operation is not atomic anymore. Currently, if the time is not set it means users are allowed in. That was there because of the backward compatibility although that could now be bent to our wills as it should be solved differently (see latest post of Lukas Hellebrandt on URI in HBAC and his ipahbacruleuri). We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original reasoning pro and against the proposed solution could be found on the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would be really nice to hear your opinions and ideas that could help us overcome this problem. Thank you, 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 18.5.2016 12:52, Jan Cholasta wrote: > On 18.5.2016 12:43, Stanislav Laznicka wrote: >> On 05/18/2016 12:38 PM, Jan Cholasta wrote: >>> On 18.5.2016 12:23, Petr Spacek wrote: On 18.5.2016 08:25, Stanislav Laznicka wrote: > On 05/17/2016 12:40 PM, Petr Spacek wrote: >> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>> Hello list, >>> >>> We had a discussion today over integrating the Time Rules into the >>> CLI and >>> WebUI and a problem came up with with the current solution. It >>> seems that >>> while having templating handled by CoSTemplates might be nice in >>> terms of easy >>> dereferencing on SSSD side (it's handled by the DS itself), it's >>> not really >>> much possible to pick one string from the multi-valued accesstime >>> attribute of >>> HBAC Rule object and modify it. >> Could you be more specific? >> >> AFAIK LDAP protocol allows this. Where is the problem? >> >> Petr^2 Spacek > I should have added we're talking CLI and WebUI here. > > Imagine you have 5 values of the accesstime attribute, each one is > about 10 > lines of iCal string, and want to change one: > > ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? >>> >>> NACK, the dns plugin should not be used as an example for anything, as >>> it breaks almost every convention in the framework. Good point :-) >> Also, typical iCalendar string is not much suitable for this approach >> (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your >> proposal is a way, of course, but not much user-friendly here. >>> >>> Removing and adding of particular accesstime values should be done by >>> a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and >>> "hbacrule-remove-accesstime rule_name accesstime". >>> >> What about modifications, thought? If not for CLI, you will still need a >> way to modify a more complex time rule in the WebUI (you do not want to >> remove a complex rule just to click through its creation all again for a >> minor change). > > Modification of an attribute value is exactly that - the old value gets > removed and the new value gets added. How it will look like in the web UI is a > completely different thing. The question here is if the intermediate state without defined time (remember, no transactions!) is acceptable or not. Does it mean that the time restriction will removed OR that access will be always denied because the rule is incomplete? Petr^2 Spacek > >>> We were thinking of a solution discussed way earlier - having our >>> own time >>> rule objects that could be referenced from each HBAC rule. That >>> way, any time >>> rule could be modified easily. As the HBAC rules are cached on the >>> SSSD side >>> periodically using the deref plugin, there should be no problem of >>> inconsistency with the server database. >>> >>> The original reasoning pro and against the proposed solution could >>> be found on >>> the pad >>> http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>> would >>> be really nice to hear your opinions and ideas that could help us >>> overcome >>> this problem. >>> >>> Thank you, >>> 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 18.5.2016 12:43, Stanislav Laznicka wrote: On 05/18/2016 12:38 PM, Jan Cholasta wrote: On 18.5.2016 12:23, Petr Spacek wrote: On 18.5.2016 08:25, Stanislav Laznicka wrote: On 05/17/2016 12:40 PM, Petr Spacek wrote: On 13.5.2016 13:50, Stanislav Laznicka wrote: Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? NACK, the dns plugin should not be used as an example for anything, as it breaks almost every convention in the framework. Also, typical iCalendar string is not much suitable for this approach (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your proposal is a way, of course, but not much user-friendly here. Removing and adding of particular accesstime values should be done by a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and "hbacrule-remove-accesstime rule_name accesstime". What about modifications, thought? If not for CLI, you will still need a way to modify a more complex time rule in the WebUI (you do not want to remove a complex rule just to click through its creation all again for a minor change). Modification of an attribute value is exactly that - the old value gets removed and the new value gets added. How it will look like in the web UI is a completely different thing. We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original reasoning pro and against the proposed solution could be found on the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would be really nice to hear your opinions and ideas that could help us overcome this problem. Thank you, Standa -- Jan Cholasta -- 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 05/18/2016 12:38 PM, Jan Cholasta wrote: On 18.5.2016 12:23, Petr Spacek wrote: On 18.5.2016 08:25, Stanislav Laznicka wrote: On 05/17/2016 12:40 PM, Petr Spacek wrote: On 13.5.2016 13:50, Stanislav Laznicka wrote: Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? NACK, the dns plugin should not be used as an example for anything, as it breaks almost every convention in the framework. Also, typical iCalendar string is not much suitable for this approach (see http://tools.ietf.org/html/rfc5545#section-4 for examples). Your proposal is a way, of course, but not much user-friendly here. Removing and adding of particular accesstime values should be done by a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and "hbacrule-remove-accesstime rule_name accesstime". What about modifications, thought? If not for CLI, you will still need a way to modify a more complex time rule in the WebUI (you do not want to remove a complex rule just to click through its creation all again for a minor change). We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original reasoning pro and against the proposed solution could be found on the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would be really nice to hear your opinions and ideas that could help us overcome this problem. Thank you, 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 18.5.2016 12:23, Petr Spacek wrote: On 18.5.2016 08:25, Stanislav Laznicka wrote: On 05/17/2016 12:40 PM, Petr Spacek wrote: On 13.5.2016 13:50, Stanislav Laznicka wrote: Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? NACK, the dns plugin should not be used as an example for anything, as it breaks almost every convention in the framework. Removing and adding of particular accesstime values should be done by a pair of commands, "hbacrule-add-accesstime rule_name accesstime" and "hbacrule-remove-accesstime rule_name accesstime". Petr^2 Spacek We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original reasoning pro and against the proposed solution could be found on the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would be really nice to hear your opinions and ideas that could help us overcome this problem. Thank you, Standa -- Jan Cholasta -- 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 18.5.2016 08:25, Stanislav Laznicka wrote: > On 05/17/2016 12:40 PM, Petr Spacek wrote: >> On 13.5.2016 13:50, Stanislav Laznicka wrote: >>> Hello list, >>> >>> We had a discussion today over integrating the Time Rules into the CLI and >>> WebUI and a problem came up with with the current solution. It seems that >>> while having templating handled by CoSTemplates might be nice in terms of >>> easy >>> dereferencing on SSSD side (it's handled by the DS itself), it's not really >>> much possible to pick one string from the multi-valued accesstime attribute >>> of >>> HBAC Rule object and modify it. >> Could you be more specific? >> >> AFAIK LDAP protocol allows this. Where is the problem? >> >> Petr^2 Spacek > I should have added we're talking CLI and WebUI here. > > Imagine you have 5 values of the accesstime attribute, each one is about 10 > lines of iCal string, and want to change one: > > ipa hbacrule-mod-accesstime rule_name --time=??? I see. In DNS plugin we do it this way: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-master-dns-zones.html#examples-add-modify-record-cli $ ipa dnsrecord-mod example.com www --a-rec 192.0.2.123 --a-ip-address 192.0.2.1 I would argue that naming of the options is weird so something easier to understand could be made. E.g. $ ipa hbacrule-mod-accesstime rule_name --orig-time=??? --time=??? Petr^2 Spacek >>> We were thinking of a solution discussed way earlier - having our own time >>> rule objects that could be referenced from each HBAC rule. That way, any >>> time >>> rule could be modified easily. As the HBAC rules are cached on the SSSD side >>> periodically using the deref plugin, there should be no problem of >>> inconsistency with the server database. >>> >>> The original reasoning pro and against the proposed solution could be found >>> on >>> the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It >>> would >>> be really nice to hear your opinions and ideas that could help us overcome >>> this problem. >>> >>> Thank you, >>> 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 05/17/2016 12:40 PM, Petr Spacek wrote: On 13.5.2016 13:50, Stanislav Laznicka wrote: Hello list, We had a discussion today over integrating the Time Rules into the CLI and WebUI and a problem came up with with the current solution. It seems that while having templating handled by CoSTemplates might be nice in terms of easy dereferencing on SSSD side (it's handled by the DS itself), it's not really much possible to pick one string from the multi-valued accesstime attribute of HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek I should have added we're talking CLI and WebUI here. Imagine you have 5 values of the accesstime attribute, each one is about 10 lines of iCal string, and want to change one: ipa hbacrule-mod-accesstime rule_name --time=??? We were thinking of a solution discussed way earlier - having our own time rule objects that could be referenced from each HBAC rule. That way, any time rule could be modified easily. As the HBAC rules are cached on the SSSD side periodically using the deref plugin, there should be no problem of inconsistency with the server database. The original reasoning pro and against the proposed solution could be found on the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would be really nice to hear your opinions and ideas that could help us overcome this problem. Thank you, 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
Re: [Freeipa-devel] [DESIGN] Time-Based HBAC Policies
On 13.5.2016 13:50, Stanislav Laznicka wrote: > Hello list, > > We had a discussion today over integrating the Time Rules into the CLI and > WebUI and a problem came up with with the current solution. It seems that > while having templating handled by CoSTemplates might be nice in terms of easy > dereferencing on SSSD side (it's handled by the DS itself), it's not really > much possible to pick one string from the multi-valued accesstime attribute of > HBAC Rule object and modify it. Could you be more specific? AFAIK LDAP protocol allows this. Where is the problem? Petr^2 Spacek > We were thinking of a solution discussed way earlier - having our own time > rule objects that could be referenced from each HBAC rule. That way, any time > rule could be modified easily. As the HBAC rules are cached on the SSSD side > periodically using the deref plugin, there should be no problem of > inconsistency with the server database. > > The original reasoning pro and against the proposed solution could be found on > the pad http://pad.engineering.redhat.com/ipa-time-based-HBAC-design. It would > be really nice to hear your opinions and ideas that could help us overcome > this problem. > > Thank you, > 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
