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] | [Elist Home]


Subject: Re: [xacml] Reviewed os 1.0 Draft 3



Anne,

Thank you for your answers.

>> We explicitly decided that returning a determinate set of
>>   Obligations was a secondary consideration to efficiency of
>>   evaluation for the standard combining algorithms.

This makes sense to me.

>>  If a user of XACML wants to return a consistent set of
>>   Obligations, then the user must define a new combining
>>   algorithm that specifies the order of evaluation or requires
>>   that all components of the policy must be fully evaluated.

So should I conclude that it's difficult to create conformance test cases
for testing obligations in case of the standard POLICY combining
algorithms?
(I know it's possible to create them in case of the standard RULE combining
algorithms.)

Thank you.

Satoshi Hada
IBM Tokyo Research Laboratory
mailto:satoshih@jp.ibm.com


|---------+---------------------------->
|         |           Anne Anderson    |
|         |           <Anne.Anderson@Su|
|         |           n.com>           |
|         |                            |
|         |           2003/02/12 05:30 |
|         |           Please respond to|
|         |           Anne.Anderson    |
|         |                            |
|---------+---------------------------->
  >--------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                          |
  |       To:       XACML TC <xacml@lists.oasis-open.org>                                                                    |
  |       cc:                                                                                                                |
  |       Subject:  [xacml] Reviewed os 1.0 Draft 3                                                                          |
  |                                                                                                                          |
  |                                                                                                                          |
  >--------------------------------------------------------------------------------------------------------------------------|



I reviewed the os 1.0 Draft 3 against the errata, and everything
looks fine except that [XF] and [XQO] are inconsistent.  I just
submitted a proposal for merging those.

I have also looked more closely into Satoshi's questions about
which obligations should be returned.  Here is how I would
respond.

2.1 Deny-overrides
  Q2.1.1 Deny-overrides does not specify order of evaluation.  If
         P1 is evaluated first, then P2 must be evaluated only if
         it contains any "Deny" rules.  Only if P2 is evaluated
         must the obligations associated with P2 be returned.
         Likewise, if P2 is evaluated first, then P1 might not be
         evaluated, and its obligations might not be returned.

  Q2.1.2 If P1 is evaluated first, then P2 need not be
         evaluated.  Likewise, if P2 is evaluated first, then P1
         need not be evaluated.  A policy's obligations are
         returned only if it is evaluated.

2.2 Permit-overrides
  Same answers

2.3 First-applicable
  Q2.3.1 If P1 is the first applicable, then P2 will not be
         evaluated and the obligations associated with P2 will
         not be returned.  First-applicable specifes order of
         evaluation.
  Q2.3.2 Same answer.

I think the general answer is:

  We had to make trade-offs between efficient evaluation of
  policies and determinate results.  We defined "Deny-overrides"
  in such a way that it returns a determinate :-)
  "Permit/Deny/Indeterminate" result, since that was the combiner
  where users are most likely to insist on a determinate result.
  Note that this can require at least searching all rules in all
  policies just in case one of them has an effect of "Deny".  We
  also defined "First-applicable" such that it specifies an order
  of evaluation.  That order does not apply to inner combining
  algorithms, so there could still be some variation in order and
  completeness of evaluation.

  In general we let efficiency of evaluation be the primary goal.
  One evaluation order might return "Indeterminate" while another
  evaluation order might return a non-Indeterminate value, but if
  a non-Indeterminate value is returned, it will always be the
  same one.  If a PDP can evaluate P2 more easily than P1, then
  (for most algorithms) the PDP can evaluate P2 before evaluating
  P1.  We do not insist that the complete tree of policies and
  rules be evaluated.

  Obligations are returned only for policy sets, policies, and
  rules that are actually evaluated.

  We explicitly decided that returning a determinate set of
  Obligations was a secondary consideration to efficiency of
  evaluation for the standard combining algorithms.  Our
  combining algorithms do not force complete evaluation of all
  policy sets, policies, and rules, and they do not force a
  particular order of evaluation (except for the top-level
  "First-Applicable").

  If a user of XACML wants to return a consistent set of
  Obligations, then the user must define a new combining
  algorithm that specifies the order of evaluation or requires
  that all components of the policy must be fully evaluated.

Anne
--
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>







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


Powered by eList eXpress LLC