[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml-comment] another little question: XACML 3.0 RBAC profile:line 718-720
Hi Jan, Thanks for the comment. I can see that the text is ambiguous. I think the intent is that policy sets should be allowed. I will add this item to the list of comments on the CD-1 public review. Regards, Erik Jan Herrmann wrote: > Hi all, > In line 718-720 of the XACML 3.0 RBAC profile it remains unclear whether a > Permission <PolicySet> can have an included <PolicySet> (Note: not a > referenced one). I think this might be helpful and should therefore be > specified more clearly. Assume e.g. a role that has assigned a lot of rules > and one wants to structure these e.g. for performance reasons. > regards jan > > ________________________________________ > > Jan Herrmann > Dipl.-Inform., Dipl.-Geogr. > > wissenschaftlicher Mitarbeiter > > Technische Universität München > Institut für Informatik > > Lehrstuhl für Angewandte Informatik / Kooperative Systeme > > Boltzmannstr. 3 > 85748 Garching > > Tel: +49 (0)89 289-18692 > Fax: +49 (0)89 289-18657 > www11.informatik.tu-muenchen.de > ________________________________________ > > > >> -----Ursprüngliche Nachricht----- >> Von: Jan Herrmann [mailto:herrmanj@in.tum.de] >> Gesendet: Freitag, 14. August 2009 16:04 >> An: 'Tyson, Paul H' >> Cc: xacml-comment@lists.oasis-open.org >> Betreff: AW: [xacml-comment] just on little questions >> >> Thanks for your explanations. I like your conclusion that "Best practice >> is >> to write targets that show the business intent of the policy or rule as >> clearly as possible". I spent quite some time thinking of normal forms for >> rules and when to combine similar rules (that used only conjunctions) into >> a >> rule with "OR" expressions in it's target or condition. In the end I came >> to >> a similar conclusion that depending on your objectives (like e.g. get a >> most >> concise representation, get a form that is easier to understand or get a >> form that is easier to analyse...) different approaches have to be >> applied. >> >> Greets Jan >> >> >> >> >>> -----Ursprüngliche Nachricht----- >>> Von: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com] >>> Gesendet: Freitag, 14. August 2009 15:27 >>> An: Jan Herrmann; Ludwig Seitz >>> Cc: xacml-comment@lists.oasis-open.org >>> Betreff: RE: [xacml-comment] just on little questions >>> >>> While any boolean schema can be expressed as a disjunctive list of >>> conjunctions (AnyOf/AllOf), this can require repeating some Match >>> conditions in several conjunctions. You can factor out repeated >>> expressions into the implied conjunction provided by <Target> using >>> multiple AnyOf elements. The resulting expression is not normalized, >>> >> but >> >>> can be more concise and easier to understand from a business standpoint. >>> >>> Jan is right--most of the examples in the core spec use multiple AnyOf >>> elements without any good reason. All except 4.2.4.4 could be written >>> >> as >> >>> a list of Match elements in one AnyOf/AllOf. If we take S,R1,R2,A1,A2 >>> >> for >> >>> the resource, subject, and action matches in 4.2.4.4, the intent is: >>> >>> (S & R1 & R2) & (A1 | A2) >>> >>> As written, the example is like: >>> (Target >>> (AnyOf (AllOf (S))) >>> (AnyOf (AllOf (R1,R2))) >>> (AnyOf (AllOf (A1)) (AllOf (A2)))) >>> >>> The normal form of the boolean schema is >>> (S & R1 & R2 & A1) | (S & R1 & R2 & A2) >>> >>> Which in XACML3 would be like: >>> (Target (AnyOf (AllOf (S,R1,R2,A1)) (AllOf (S,R1,R2,A2)))) >>> >>> But this repeats S, R1, and R2. >>> >>> (Note that the normal form is useful for testing policies, because it is >>> easier to derive conditions that will make the schema true or false. >>> Targets can easily be put into normal form by syntax transformation >>> >> alone, >> >>> but Conditions are more difficult.) >>> >>> The logical schema is most compactly expressed in XACML as: >>> (Target (AnyOf (AllOf (S,R1,R2))) (AnyOf (AllOf (A1)) (AllOf (A2)))) >>> >>> which seems to correspond to the business intent of the policy. >>> >>> I found the 2.0 syntax very limiting for targeting multiple combinations >>> of attributes in different categories. I don't think there is any >>> >> reason >> >>> for a "best practice" to segregate target matching conditions by >>> >> category. >> >>> Best practice is to write targets that show the business intent of the >>> policy or rule as clearly as possible. >>> >>> --Paul >>> >>> >>>> -----Original Message----- >>>> From: Jan Herrmann [mailto:herrmanj@in.tum.de] >>>> Sent: Friday, August 14, 2009 03:44 >>>> To: 'Ludwig Seitz' >>>> Cc: xacml-comment@lists.oasis-open.org >>>> Subject: AW: [xacml-comment] just on little questions >>>> >>>> thanks for the quick reply. >>>> Good to hear that it is only a design recommendation to >>>> separate Matches for different attribute categories under >>>> different AnyOf elements. >>>> Maybe a little note when explaining the examples might help >>>> understanding the reasoning behind this design recommendation. >>>> >>>> If I may remark, I am not sure at all if it is a good idea to >>>> define targets that way? You said that this helps >>>> managing/editing policies. How exactly? I assume you mean >>>> that the rules become more readable. First this assumes that >>>> you edit your policies in a text editor. Second I am >>>> wondering why you are not using comments. Adding unnecessary >>>> and/or statements around the real formula just for >>>> readability reasons, seems to be a very unclean solution. >>>> >>>> Regards >>>> Jan >>>> >>>> >>>> >>>> >>>>> -----Ursprüngliche Nachricht----- >>>>> Von: Ludwig Seitz [mailto:ludwig@axiomatics.com] >>>>> Gesendet: Freitag, 14. August 2009 10:12 >>>>> An: Jan Herrmann >>>>> Cc: xacml-comment@lists.oasis-open.org >>>>> Betreff: Re: [xacml-comment] just on little questions >>>>> >>>>> On Fri, 2009-08-14 at 09:55 +0200, Jan Herrmann wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Just a one little question: >>>>>> >>>>>> >>>>>> >>>>>> In XACML v.3.0 examples (e.g. in the XACML 3.0 core and >>>>>> >>>> hierarchical >>>> >>>>>> RBAC profile line 241) you always open and close AnyOf elements >>>>>> after each indicidual match element. I don't understand >>>>>> >>>> why this is >>>> >>>>>> done this way and as I saw it in various examples I >>>>>> >>>> wonder if it is >>>> >>>>>> done with some special purpose. From my point of view the >>>>>> >>>> same could >>>> >>>>>> be done with only one <AnyOf> element under target that has under >>>>>> its only AllOf child all the Match elements. >>>>>> >>>>>> >>>>>> >>>>> It a sort of leftover from XACML 2.0 (although I think it >>>>> >>>> makes sense, >>>> >>>>> as I'll explain shortly). >>>>> >>>>> The AnyOf elements in 2.0 where named Subjects, Resources, >>>>> >>>> Actions and >>>> >>>>> Environments and would contain only Subject, Resource etc Matches. >>>>> >>>>> Although it's possible in 3.0 to throw all Match elements under one >>>>> AnyOf/AllOf or make a DNF, I believe it's better to keep on >>>>> >>>> doing as >>>> >>>>> in XACML 2.0 and separate Matches for different attribute >>>>> >>>> categories >>>> >>>>> under different AnyOf elements. The performance hit is minimal (if >>>>> any), and managing/editing policies is greatly simplified if the >>>>> Matches are cleanly separated. >>>>> >>>>> /Ludwig >>>>> >>>>> >>>>> -- >>>>> Ludwig Seitz, PhD | Axiomatics AB >>>>> Training & Development | Electrum 223 >>>>> Phone: +46 (0)703 83 08 00 | S-164 40 Kista, Sweden >>>>> Mail: ludwig@axiomatics.com | >>>>> >>>> >>>> -- >>>> This publicly archived list offers a means to provide input >>>> to the OASIS eXtensible Access Control Markup Language (XACML) TC. >>>> >>>> In order to verify user consent to the Feedback License terms >>>> and to minimize spam in the list archive, subscription is >>>> required before posting. >>>> >>>> Subscribe: xacml-comment-subscribe@lists.oasis-open.org >>>> Unsubscribe: xacml-comment-unsubscribe@lists.oasis-open.org >>>> List help: xacml-comment-help@lists.oasis-open.org >>>> List archive: http://lists.oasis-open.org/archives/xacml-comment/ >>>> Feedback License: >>>> http://www.oasis-open.org/who/ipr/feedback_license.pdf >>>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >>>> Committee: >>>> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml >>>> >>>> >>>> >> -- >> This publicly archived list offers a means to provide input to the >> OASIS eXtensible Access Control Markup Language (XACML) TC. >> >> In order to verify user consent to the Feedback License terms and >> to minimize spam in the list archive, subscription is required >> before posting. >> >> Subscribe: xacml-comment-subscribe@lists.oasis-open.org >> Unsubscribe: xacml-comment-unsubscribe@lists.oasis-open.org >> List help: xacml-comment-help@lists.oasis-open.org >> List archive: http://lists.oasis-open.org/archives/xacml-comment/ >> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php >> Committee: http://www.oasis- >> open.org/committees/tc_home.php?wg_abbrev=xacml >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]