OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]