[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]