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: [xacml] A draft proposal for a new work item: condition reference


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]