[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] A problem with the Target
>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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]