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 for algorithm






Hi, Polar

>this proposal seems to limit you to ONE parameter per rule. Is that
correct?

No. It is possible to assign two parameters on a rule. For example,

<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 RuleId="R1">
      ...
   </Rule>
</Policy>

I think that the policy writer who is going to write parameters must know
how each parameter is assigned to which rule, and its semantics. I feel
that some policy authoring tool must support this type of policy authoring
process.

Actually, original proposal came from Simon and the sprit behind his
proposal is that the semantics of each parameter is up to each combining
algorithm.

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

Probably yes, for flexibility. For example, if each rule has
meta-information such as creater and issue-date, and the evaluation
algorithm uses these two values for determining the priority (Alice's rule
takes precedence over Bob's rule and newly created rule takes precedence) ,
we therefore need two parameters per rule. Using the same policy example,

<Policy algid="priority-rule-combo-algo">
   <CombinerParameters>
     <CombinerParameter ParameterName="creater">
       <AttributeValue DataType="string">Alice</AttributeValue>
     </CombinerParameter>
     <CombinerParameter ParameterName="issue-date">
       <AttributeValue DataType="date">Jan 30 2004</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <Rule RuleId="R1">
      ...
   </Rule>
</Policy>

Another possibility is to specify these values as local schema:

<Policy algid="priority-rule-combo-algo">
   <CombinerParameters>
     <CombinerParameter ParameterName="certificate">
       <AttributeValue DataType="urn:mycert" >
         <cert:credential>
           <cert:subject-name>Alice</cert:subject-name>
           <cert:issue-date>Jan 30 2004</cert:issue-date>
         </cert:credential>
        </AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <Rule RuleId="R1">
      ...
   </Rule>
</Policy>

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

I am perfectly ok with the type-oriented system because XACML policy IS the
type system. I think the above examples also conforms to your proposed
schema.

I have one concern about your suggestion to fix the mechanism how to assign
a combiner parameter to each rule. It may be the case that <Policy> (not
<Rule>) needs some parameters. So we would have to distinguish both. Easier
way would be to add one more attribute "ParameterRef"that specifies the
target of the parameter. For example,

<Policy PolicyId="P1" algid="priority-rule-combo-algo">
   <CombinerParameters ParameterRef="P1">
     <CombinerParameter ParameterName="creater">
       <AttributeValue DataType="string">Alice</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <CombinerParameters ParameterRef="R1">
     <CombinerParameter ParameterName="creater">
       <AttributeValue DataType="string">Bob</AttributeValue>
     </CombinerParameter>
   </CombinerParameters>
   <Rule RuleId="R1">
      ...
   </Rule>
</Policy>

The first parameter is for policy "P1" and the second parameter is for rule
"R1".  It frees us from the problems where to write and how to assign.

Best,
Michiharu



                                                                           
             Polar Humenn                                                  
             <polar@syr.edu>                                               
                                                                        To 
             2004/03/26 04:22          Michiharu Kudoh/Japan/IBM@IBMJP     
                                                                        cc 
                                       "'xacml@lists.oasis-open.org'"      
                                       <xacml@lists.oasis-open.org>        
                                                                   Subject 
                                       Re: [xacml] Summary of the          
                                       discussion on WI#10: Parameter for  
                                       algorithm                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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
.
>

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]