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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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


Subject: Re: [xacml] A draft proposal for a new work item: condition reference



I have forgotten to respond the question from Bill. Your question is "why
is Id attribute in the ApplyType optional?".
My answer is "for backward compatibility". If it is mandatory, every
condition expression (no Id attribute) generated for XACML 1.0 results in
invalid against 1.1 schema.

Michiharu Kudo



                                                                                                                                                    
                      bill parducci                                                                                                                 
                      <bill.parducci@ov        To:       XACML TC <xacml@lists.oasis-open.org>                                                      
                      erxeer.com>              cc:                                                                                                  
                                               Subject:  Re: [xacml] A draft proposal for a new work item: condition reference                      
                      2003/04/22 23:21                                                                                                              
                                                                                                                                                    
                                                                                                                                                    



i like this, i think that it is in line with practical policy creation.
curious though, as to why ApplyType:Id is optional? at first look it
seems like the ApplyType structure would itself have potential reuse,
sort of a 'condition collection/profile'.

b

Michiharu Kudoh wrote:
> This message includes motivating examples and a draft proposal for schema
> modifications. I welcome any comments on this.
>
>    Motivating example 1: ConditionIdReference
>
> If a certain condition specification is described in other rules, it
might
> be better to define it at some place and refer to it from inside the
rule.
> In the following policy, each rule specify the identical condition that
> checks whether "age is between 20 and 60".
>
> 1a) Policy using current schema
>
> <Policy>
>   <Rule Effect = "Permit">
>     <Target>... target 1
>     <Condition 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>
>   <Rule Effect = "Permit">
>     <Target> ... target 2
>     <Condition 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>
> </Policy>
>
> 1b) The following example shows a new policy specification when we allow
> condition definition and condition reference.
>
> <Policy>
>   <Condition Id="CheckAge" 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>CheckAge</ConditionIdReference>
>   </Rule>
>   <Rule Effect = "Permit">
>     <Target> ... target 2
>     <ConditionIdReference>CheckAge</ConditionIdReference>
>   </Rule>
> </Policy>
>
>    Motivating example 2: ApplyIdReference (more fine-grained reference
than
>    ConditionidReference)
>
> It is often the case that the condition consists of a set of
subconditions
> that are connected by AND (or OR). In the following policy, the first
rule
> checks whether "age is between 20 and 60, state is CA and cell phone is
> yes" and the second rule checks whether "age is between 20 and 60, state
is
> NY and cell phone is no".
>
> 2a) Policy using current schema
>
> <Policy>
>   <Rule Effect = "Permit">
>     <Target>... target 1
>     <Condition 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 ...
>       <Apply FunctionId="...string-equal">
>          ... state is CA ...
>       <Apply FunctionId="...string-equal">
>          ... cell phone is yes...
>     </Condition>
>   </Rule>
>   <Rule Effect = "Permit">
>     <Target> ... target 2
>     <Condition 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 ...
>       <Apply FunctionId="...string-equal">
>          ... state is NY ...
>       <Apply FunctionId="...string-equal">
>          ... cell phone is no...
>     </Condition>
>   </Rule>
> </Policy>
>
> 2b)  The following example shows a new policy specification when we allow
> Apply definitions and Apply references.
>
> <Policy>
>   <Apply Id="CheckAgeOnly" 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 ...
>   </Apply>
>   <Apply Id="CheckCAandCellphone" FunctionId="...function:and">
>     <Apply FunctionId="...string-equal">
>        ... state is CA ...
>     <Apply FunctionId="...string-equal">
>        ... cell phone is yes...
>   </Apply>
>   <Apply Id="CheckNYandNoCellphone" FunctionId="...function:and">
>     <Apply FunctionId="...string-equal">
>        ... state is NY ...
>     <Apply FunctionId="...string-equal">
>        ... cell phone is no...
>   </Apply>
>   <Rule Effect = "Permit">
>     <Target>... target 1
>     <Condition FunctionId="...function:and">
>       <ApplyIdReference>CheckAgeOnly</ApplyIdReference>
>       <ApplyIdReference>CheckCAandCellphone</ApplyIdRefrerence>
>     </Condition>
>   </Rule>
>   <Rule Effect = "Permit">
>     <Target> ... target 2
>     <Condition FunctionId="...function:and">
>       <ApplyIdReference>CheckAgeOnly</ApplyIdReference>
>       <ApplyIdReference>CheckNYandNoCellphone</ApplyIdReference>
>     </Condition>
>   </Rule>
> </Policy>
>
>
>    A draft proposal for schema modifications
>
> I tried to make minimum changes to the current schema definition. I
> underlined where I modified the schema.
>
> 1. Policy element allows to specify definitions of Condition and Apply
> elements that are referred from inside the Rule element.
>
> <xs:element name="Policy" type="xacml:PolicyType"/>
> <xs:complexType name="PolicyType">
>   <xs:sequence>
>     <xs:element ref="xacml:Description" minOccurs="0"/>
>     <xs:element ref="xacml:PolicyDefaults" minOccurs="0"/>
>     <xs:element ref="xacml:Condition" minOccurs="0"/>
>     <xs:element ref="xacml:Apply" 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>
>
>
> 2. Rule element allows to specify ConditionIdReference element as well as
> Condition element.
>
> <xs:element name="Rule" type="xacml:RuleType"/>
> <xs:complexType name="RuleType">
>   <xs:sequence>
>     <xs:element ref="xacml:Description" minOccurs="0"/>
>     <xs:element ref="xacml:Target" minOccurs="0"/>
>     <xs:choice>
>       <xs:element ref="xacml:Condition" minOccurs="0"/>
>       <xs:element ref="xacml:ConditionIdReference" minOccurs="0"/>
>     </xs:choice>
>   </xs:sequence>
>   <xs:attribute name="RuleId" type="xs:anyURI" use="required"/>
>   <xs:attribute name="Effect" type="xacml:EffectType" use="required"/>
> </xs:complexType>
>
>
> 3. New elements used to refer Condition and Apply elements
>
> <xs:element name="ConditionIdReference" type="xs:IDREF"/>
> <xs:element name="ApplyIdReference" type="xs:IDREF"/>
>
>
> 4. Condition element allows ApplyIdReference element an ID attribute
>
> <xs:element name="Condition" type="xacml:ApplyType"/>
> <!-- -->
> <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"/>
>   <xs:attribute name="Id" type="xs:ID" use="optional"/>
> </xs:complexType>
>
> Michiharu Kudo
>
>








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