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] Summary of the discussion on WI#10: Parameter foralgorithm



Michiharu,

If it is the intent of combining algorithm to associate parameters with a
rules, this proposal seems to limit you to ONE parameter per rule. Is that
correct? The difference is the effective semantic type of the combining
algorithms.

For example, do we want the capability to have two or XACML parameters
associated with each rule?

    (Params (Param priority 2)(Param weight 10))(Rule ...)
    (Params (Param priority 3)(Param weight 50))(Rule ...)

Please, excuse me for not using <XML/> :)

The other question is that do we want to bring the parameter values into
the XACML type system?

The two questions are related as if we take the approach with the ability
to associate just ONE parameter per rule, then the combining algorithm must
perform ALL the parsing of the parameter content, in case it does want
multiple information items per rule.  Also, no referencing of
variable expressions can be done, because the combining algorithm
will/should not have access to the evaluation environment (that's
different than the ReqeustContext Environment).

However, if we take the approach that a Parameter(s) MUST be an XACML
Expression(s), then the expression(s) may be evaluated before being passed
to the combining algorithm.

The later approach can work semantically within type system. That approach
will be more syntax restrictive, and it is bit better for type safety.

How about:

  <xs:element name="CombinerParameters"
  type="xacml:CombinerParametersType"/>
  <xs:complexType name="CombinerParametersType">
  <xs:sequence>
  <xs:element ref="xacml:CombinerParameter" minOccurs="0"
  maxOccurs="unbounded"/>
  </xs:sequence>
  </xs:complexType>
  <!-- -->
  <xs:element name="CombinerParameter" type="xacml:CombinerParameterType"/>
  <xs:complexType name="CombinerParameterType">
  <xs:sequence>
<!-- Change Is Here -->
  <xs:element ref="xacml:ExpressionType" minOccurs="0"
  maxOccurs="unbounded"/>
<!--             -->
  </xs:sequence>
  <xs:attribute name="ParameterName" type="string" use="required"/>
  </xs:complexType>

2. Example policies would be:

 <Policy algid="priority-rule-combo-algo">
   <CombinerParameters>
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="...:integer">2</AttributeValue>
     </CombinerParameter>
     <CombinerParameter ParameterName="weight">
       <AttributeValue DataType="...:integer">10</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <CombinerParameters>
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="...:integer">10</AttributeValue>
     </CombinerParameter>
     <CombinerParameter ParameterName="weight">
       <AttributeValue DataType="...:integer">50</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <Rule effect="permit">... rule 1...</Rule>
   <Rule effect="permit">... rule 2 ...</Rule>
 </Policy>

 and

 <Policy algid="priority-rule-combo-algo">
   <CombinerParameters>
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="...:integer">2</AttributeValue>
     </CombinerParameter>
     <CombinerParameter ParameterName="weight">
       <AttributeValue DataType="...:integer">10</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <Rule effect="permit">... rule 1...</Rule>

   <CombinerParameters>
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="...:integer">10</AttributeValue>
     </CombinerParameter>
     <CombinerParameter ParameterName="weight">
       <AttributeValue DataType="...:integer">50</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <Rule effect="permit">... rule 2 ...</Rule>
 </Policy>

Note, that in Michiharu's example,

   <CombinerParameters>
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="...:integer">10</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <CombinerParameters>
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="...:integer">50</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>

and

   <CombinerParameters>
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="...:integer">10</AttributeValue>
     </CombinerParameter>
     <CombinerParameter ParameterName="priority">
       <AttributeValue DataType="...:integer">50</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>

are really considered equivalent. In my version, they are distinct
entities.

Cheers,
-Polar


> 3. Some concerns (raised by Polar)
>
> Q1 How flexible should we allow for the combiner parameter? No limitation?
> Q2 Should we provide a way to use XACML useful syntax (reference,
> expressions etc.) for specifying combininng parameters?
>
> There are two ways to address the above issues:
> - No further syntactical limitation for combiner parameter
> - Enforce more restriction on syntax for combiner parameter
> (XACML-compliant syntax e.g. attribute value etc.)
>
> 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.
>


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