MHonArc v2.5.0b2 -->
xacml message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xacml] Proposal on item 7 ConditionReference
On Thu, 4 Dec 2003, Michiharu Kudoh wrote:
> Hi, Polar
>
> Thank you for your comments. I see what you mean and it might also be a
> good way to reuse values according to your idea. Actually, I did not intend
> that level (value-level or LET level) of flexibility. I was only concerned
> with the Condition level reusability. More accurately, policy author can
> define any condition (that returns T/F) and refers it from inside the
> condition or apply element. It greatly reduces the duplication and also
> keep the spec simpler. LET like construct might be useful in more
> complicated expression cases but that is beyond my use cases...
>
> So now I agree that you have problems with "ApplyIdRef" in the sense that
> it can return arbitrary data type (I missed it). So my opinion is:
I definately don't have "problems" with it. I like the idea, and I see no
problem with just making it like a LET construct for general values,
whether they are used for conditions or in other expressions. I think
pretty much if we do condition references correctly we get the other for
basically free.
-Polar
> - limit to Condition level reference (or Boolean return type)
> - delete schema modifications with regard to ApplyIdRef
> - replace ApplyIdRefeference element with ConditionIdReference element
> defined in ApplyType in my previous proposal
> Does it make sense?
>
> Cheers,
> -Michiharu
>
>
>
>
> Polar Humenn
> <polar@syr.edu> To: Michiharu Kudoh/Japan/IBM@IBMJP
> cc: XACML TC <xacml@lists.oasis-open.org>
> 2003/12/04 10:02 Subject: Re: [xacml] Proposal on item 7 ConditionReference
>
>
>
>
>
>
>
> Michiharu-san,
>
> Thanks for your proposal on condition reference. However, it looks like
> you've added something else, called your "ApplyIdRef", which performs the
> same function except for arbitrary typed values, where as the condition
> references logical values.
>
> I think these two things can really be consolidated.
>
> What we are really doing is specifying value that can be referenced in
> other expressions, so safe on space, and also perhaps, to save evaluation
> time, if that value is to be used more than once within the same policy.
>
> This approach is just like giving a variable a value in any other
> programming language. As Gerald Brose said to me in Milan, "What they want
> is a 'let' statement", to which I concurred.
>
> So, now if we are going to go that way, lets do it in general.
>
> I would suggest using the words
>
> <VariableDef VarId="x">
> .... -- This doesn't have to be ApplyType, but just a value.
> </VariableDef>
>
> <VariableRef VarId="x>
>
> The type of a VariableDef will be deduced by the value or expression it
> contains, and the type of the corresponding VariableRef will coincide.
>
> A condition is merely a value of type xs:boolean, and a condition
> reference, just to be consistent with the syntax we have, will reference a
> variable.
>
> <ConditionRef VarId="y">
>
> And the restriction is that the variable defined for "y" must be
> xs:boolean.
>
> How does that approach sound?
>
> Cheers,
> -Polar
>
>
> On Thu, 20 Nov 2003, Michiharu Kudoh wrote:
>
> >
> >
> >
> >
> > >7. ConditionReference
> > >
> > > General proposal now accepted. Waiting for the specific
> > > line-by-line specification changes.
> >
> > The following is a proposal on Item 7: ConditionReference
> >
> > Regarding the motivating examples, please refer to the original draft
> > proposal:
> > http://lists.oasis-open.org/archives/xacml/200304/msg00039.html
> >
> > 1. Overview
> >
> > This proposal extends XACML 1.1 to support more succinct condition
> > specification. The extension allows policy writers to define a set of
> > condition expressions at a place and refer to it from inside the policy.
> > This condition reference does not extend beyond the policy boundary to
> meet
> > the agreement that the minimum administration unit is a policy. The
> > extension consists of two parts: condition-level reference and
> apply-level
> > reference.
> >
> > Condition-level reference allows a Rule to contain a ConditionIdReference
> > element as an alternative to a Condition element. The ConditionReference
> > would identify a ConditionDef element specified below Policy element.
> This
> > allows a single Condition to be re-used in Rules under different Targets.
> A
> > ConditionId attribute is added to the ConditionDef element to support
> this.
> >
> > To support finer-grained condition reference, apply-level reference
> allows
> > a condition or apply to contain a ApplyIdReference element as an
> > alternative to an Apply element. The ApplyReference would identify a
> > ApplyDef element specified below Policy element. This allows a single
> Apply
> > to be re-used in Conditions or Apply in Rules under different Conditions
> > and Targets. An ApplyId attribute is added to the ApplyDef element to
> > support this.
> >
> > 2. Sample policy specifications
> >
> > <Policy>
> > <ConditionDef ConditionId="CheckAgeBetween20-60"
> > FunctionId="...function:and">
> > <Apply FunctionId="...integer-greater-than-or-equal">
> > ... age is equal or greater than 20 ...
> > <Apply FunctionId="...integer-less-than-or-equal">
> > ... age is equal or less than 60 ...
> > </Condition>
> > <Rule Effect = "Permit">
> > <Target>... target 1
> > <ConditionIdReference>CheckAgeBetween20-60</ConditionIdReference>
> > </Rule>
> > <Rule Effect = "Permit">
> > <Target> ... target 2
> > <ConditionIdReference>CheckAgeBetween20-60</ConditionIdReference>
> > </Rule>
> > </Policy>
> >
> >
> > 3. Specification modifications
> > (based on the XACML 1.1 pdf doc as of Aug 7, 2003)
> >
> > + Line 2083, Section 5.20, insert
> > <xs:element ref="xacml:ConditionDef" minOccurs="0"/>
> > <xs:element ref="xacml:ApplyDef" minOccurs="0"/>
> >
> > + Line 2105, Section 5.20, insert
> > <ConditionDef> [Optional]
> > Defines a set of condition expressions referred from the rules in the
> > enclosing policy.
> >
> > <ApplyDef> [Optional]
> > Defines a set of apply expressions referred from the rules in the
> enclosing
> > policy.
> >
> > + Line 2135, new Section 5.22 and 5.23, insert
> > 5.22. Element <ConditionDef>
> > The <ConditionDef> element SHALL specify a set of condition expressions
> > referred from the rules in the enclosing policy.
> >
> > <xs:element name="ConditionDef" type="xacml:ConditionDefType"/>
> > <xs:complexType name="xacml:ConditionDefType">
> > <xs:complexContent>
> > <xs:extension base="xacml:ApplyType">
> > <xs:attribute name="ConditionId" type="xs:anyURI" use="required" />
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > 5.23. Element <ApplyDef>
> > The <ApplyDef> element SHALL specify a set of apply expressions referred
> > from the rules in the enclosing policy.
> >
> > <xs:element name="ApplyDef" type="xacml:ApplyDefType"/>
> > <xs:complexType name="xacml:ApplyDefType">
> > <xs:complexContent>
> > <xs:extension base="xacml:ApplyType">
> > <xs:attribute name="ApplyId" type="xs:anyURI" use="required" />
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > + Line 2143, old Section 5.22, insert
> > <xs:element ref="xacml:ConditionIdReference" minOccurs="0"/>
> >
> > + Line 2165, Section 5.22, insert
> > <ConditionIdReference> [Optional]
> > The <xacml:ConditionIdReference> element SHALL be used to reference a
> > <ConditionDef> element by id. If <ConditionIdReference> is a URL, then it
> > MAY be resolvable to the <Condition>. The mechanism for resolving a
> > condition reference to the corresponding condition is outside the scope
> of
> > this specification.
> > <xs:element name="ConditionIdReference" type="xs:anyURI"/>
> > Element <ConditionIdReference> is of xs:anyURI simple type.
> >
> > + Line 2182, Section 5.25, modify the line
> > call. The <Apply> element can be applied to any combination of <Apply>,
> > <ApplyIdReference>,
> >
> > + Line 2190, Section 5.25, insert
> > <xs:element ref="xacml:ApplyIdReference"/>
> >
> > + Line 2208, Section 5.25, insert
> > <ApplyIdReference> [Optional]
> > A function call reference.
> >
> >
> > 4. Schema modifications
> > The following lists schema fragments affected by this proposal.
> >
> > <xs:complexType name="PolicyType">
> > <xs:sequence>
> > <xs:element ref="xacml:Description" minOccurs="0"/>
> > <xs:element ref="xacml:PolicyDefaults" minOccurs="0"/>
> > <xs:element ref="xacml:ConditionDef" minOccurs="0"/>
> > <xs:element ref="xacml:ApplyDef" minOccurs="0"/>
> > <xs:element ref="xacml:Target"/>
> > <xs:element ref="xacml:Rule" minOccurs="0"
> > maxOccurs="unbounded"/>
> > <xs:element ref="xacml:Obligations" minOccurs="0"/>
> > </xs:sequence>
> > <xs:attribute name="PolicyId" type="xs:anyURI" use="required"/>
> > <xs:attribute name="RuleCombiningAlgId" type="xs:anyURI"
> > use="required"/>
> > </xs:complexType>
> >
> > <xs:element name="ConditionDef" type="xacml:ConditionDefType"/>
> > <xs:complexType name="xacml:ConditionDefType">
> > <xs:complexContent>
> > <xs:extension base="xacml:ApplyType">
> > <xs:attribute name="ConditionId" type="xs:anyURI" use="required" />
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > <xs:element name="ApplyDef" type="xacml:ApplyDefType"/>
> > <xs:complexType name="xacml:ApplyDefType">
> > <xs:complexContent>
> > <xs:extension base="xacml:ApplyType">
> > <xs:attribute name="ApplyId" type="xs:anyURI" use="required" />
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> >
> > <xs:complexType name="RuleType">
> > <xs:sequence>
> > <xs:element ref="xacml:Description" minOccurs="0"/>
> > <xs:element ref="xacml:Target" minOccurs="0"/>
> > <xs:element ref="xacml:Condition" minOccurs="0"/>
> > <xs:element ref="xacml:ConditionIdReference" minOccurs="0"/>
> > </xs:sequence>
> > <xs:attribute name="RuleId" type="xs:anyURI" use="required"/>
> > <xs:attribute name="Effect" type="xacml:EffectType"
> use="required"/>
> > </xs:complexType>
> >
> > <xs:complexType name="ApplyType">
> > <xs:choice minOccurs="0" maxOccurs="unbounded">
> > <xs:element ref="xacml:Apply"/>
> > <xs:element ref="xacml:ApplyIdReference"/>
> > <xs:element ref="xacml:Function"/>
> > <xs:element ref="xacml:AttributeValue"/>
> > <xs:element ref="xacml:SubjectAttributeDesignator"/>
> > <xs:element ref="xacml:ResourceAttributeDesignator"/>
> > <xs:element ref="xacml:ActionAttributeDesignator"/>
> > <xs:element ref="xacml:EnvironmentAttributeDesignator"/>
> > <xs:element ref="xacml:AttributeSelector"/>
> > </xs:choice>
> > <xs:attribute name="FunctionId" type="xs:anyURI" use="required"/>
> > <!-- Legal types for the first and subsequent operands are defined
> in> the accompanying table -->
> > </xs:complexType>
> >
> > Best,
> > Michiharu
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php
> .
> >
>
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php
> .
>
>
>
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xacml/members/leave_workgroup.php.
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]