[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] A problem with the Target
I was referring to the Boolean logic between matches - different categories seem to be harmless in this regard. Daniel. -----Original Message----- From: Anne Anderson - Sun Microsystems [mailto:Anne.Anderson@sun.com] Sent: Tuesday, February 27, 2007 2:02 PM To: Daniel Engovatov Cc: Erik Rissanen; xacml@lists.oasis-open.org Subject: Re: [xacml] A problem with the Target Perhaps we should just RECOMMEND that attribute categories not be mixed in a single set of Match predicates, with the reason that it makes policies difficult to index. Not everyone indexes policies. Regards, Anne Daniel Engovatov wrote On 02/26/07 14:03,: >>However, by looking at example below, it is clear that the 2.0 already >>allows this complex functionality for subject categories. So, my >>question is, how was it possible to index 2.0 policies? How would a 3.0 >>which would allow mixed categories be different/more difficult? > > > It will be different as it would be allowed to any other category - not > just for the relatively obscure multiple subject case. > > Naming of the elements: How about <MatchAny> and <MatchAll>? > > I think the only good thing that we can do is to firmly restrict the > possible complexity of nesting of this combinatory elements - it should > be always possible to "flatten" the rule target (depending on the rule > combining algorithm used). > > Daniel; > > > > Erik Rissanen wrote: > >>It's actually AND(OR(AND(MATCH(X)))) >> >>It used to be like this in 2.0: >> >><Target> >> <Subjects> >> <Subject> >> <SubjectMatch ...> >> <SubjectMatch ...> >> <Resources> >> ... >></Target >> >>There is an AND at the target level: both the subjects and resources >>must match. >> >>There is an OR at the <Subjects> level: at least one of the subjects > > has > >>to match. >> >>There is an AND at the <Subject> level: all matches on the subject has >>to match >> >>The 3.0 is made to be analogous so we can transform 2.0 policies into >>equivalent 3.0 policies: >> >><Target> >> <DisjunctiveMatch> >> <ConjunctiveMatch >> <Match ...> >> >>Maybe it would be better to rename the elements. > > Conjunction/disjunction > >>is a bit scientific which might scare off people, or? :-) >> >>I don't think the alternative you propose is sufficient to cover 2.0. >>For instance: >> >><Target> >> <Subjects> >> <Subject > >> <SubjectMatch subj-cat=="access-subject">group=="engineer"</> >> <SubjectMatch subj-cat=="access-subject">clearance=="A"</> >> <SubjectMatch > > subj-cat=="intermediate-subject">firewall_type=="X"</> > >> <Subject > >> <SubjectMatch subj-cat=="access-subject">group=="payroll"</> >> <SubjectMatch subj-cat=="access-subject">clearance=="A"</> >> <SubjectMatch > > subj-cat=="intermediate-subject">firewall_type=="X"</> > >> <Resources> >> <Resource> >> <ResourceMatch>resource-id=="server_23"</> >></Target >> >>(The subject-category really goes in the SubjectAttributeDesignator, > > but > >>I simplified to make it less verbose.) >> >>Regards, >>Erik >> >> >>Daniel Engovatov wrote: >> >> >>>Side note: we really should name those new elements to be <MatchAnd> > > and > >>><MatchOr>. We are cryptic as-is. >>> >>>Also - in your example, I am not sure of the intended semantics: >>>OR(AND(Match1, Match2)) - what is the outer OR is for? Should not we > > OR > >>>the subject matches there? >>> >>>Could we just introduce <MatchOr> element, have all top level matches > > to > >>>be implicitly conjunctive, and allow mixing of attribute categories >>>inside the disjunctive <MatchOr>? >>> >>>So your example would be >>><Target> >>> <MatchOr> >>> <Match ..category access-subject </...> >>> <Match .. category intermediate-subject </..> >>> </MatchOr> >>> <Match .. category resource> >>> <Match .. category action> >>></Target> >>> >>>There is no need for a conjunctive match element here, and no need > > for > >>>an arbitrary depth Boolean logic - such a target can be efficiently >>>flattened, and it is equivalent to a 2.0 target. >>> >>>Daniel. >>> >>>-----Original Message----- >>>From: Erik Rissanen [mailto:mirty@sics.se] >>>Sent: Tuesday, February 20, 2007 5:15 AM >>>To: xacml@lists.oasis-open.org >>>Subject: [xacml] A problem with the Target >>> >>>All, >>> >>>We had a discussion earlier about the generalization of the Target. > > We > >>>decided that we will not allow mixing of different attribute > > categories > >>>within the same ConjunctiveMatch since this makes indexing more >>>difficult. This is a no-no: >>> >>><Target> >>> <DisjunctiveMatch> >>> <ConjunctiveMatch> >>> <Match >>> MatchId="string-equal"> >>> <AttributeValue >>> DataType="string">Alice</AttributeValue> >>> <AttributeDesignator Category="access-subject" >>> AttributeId="subject-id" >>> DataType="string"/> >>> </Match> >>> <Match >>> MatchId="string-equal"> >>> <AttributeValue >>> DataType="string">proxy1</AttributeValue> >>> <AttributeDesignator Category="intermediate-subject" >>> AttributeId="subject-id" >>> DataType="string"/> >>> </Match> >>> </ConjunctiveMatch> >>> </DisjunctiveMatch> >>></Target> >>> >>>However, this was possible with subject categories in 2.0. So we are > > no > >>>longer backwards compatible with 2.0. >>> >>>I have no idea how to fix this, besides to allow mixing of categories > > in > >>>a ConjunctiveMatch. >>> >>>Regards, >>>Erik >>> >>> > > _______________________________________________________________________ > >>>Notice: This email message, together with any attachments, may > > contain > >>>information of BEA Systems, Inc., its subsidiaries and > > affiliated > >>>entities, that may be confidential, proprietary, copyrighted > > and/or > >>>legally privileged, and is intended solely for the use of the > > individual > >>>or entity named in this message. If you are not the intended > > recipient, > >>>and have received this message in error, please immediately return > > this > >>>by email and then delete it. >>> >>> > > > > _______________________________________________________________________ > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692 _______________________________________________________________________ Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]