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: [xacml] policy subcommittee meeting on Dec. 10 - minutes


Minutes of the policy committee concall (Monday Dec. 10th)
---------------------------------------------------------

It is decided to include a new attribute in the rule which states the
type of the rule. A possible value is ``permit'' (meaning the rule
specifies a permission). There is a long discussion about allowing a
``deny'' element (meaning negative rules).

The current draft does not support explicit deny semantics for the
rules but ``simulates'' them through the use of boolean operators for
combining single rules. As an example if you want to give access to
all EMPLOYEES but JOE, you would specify a rule where the
pre-condition would give the permission to the principals satifying
the predicates ``user is in EMPLOYEES but user is not JOE''. You would
then combine this rule in AND with other rules.

While operators can indeed be used in several cases instead of
``deny'' rules, they cannot however substitute them completely. The
problem is that the ``is not JOE'' portion of the precondition above
applies only within the rule and it has not effect on other rules of
the policy (even if the rule is combined in AND).

There is therefore a discussion on the explicit support of negative
rules (``deny''), where the presence of ``permit'' and ``deny'' rule
for a same request could be solved in different ways (denials take
precedence being an example of that).

It is noted that deny semantics can bring side effects in the policy
composition process (XACML allows policies to be combined with boolean
operator to produce a global policy, e.g., P = P1 AND P2; P = P1 OR
P2).

For instance, suppose global policy P is defined as P=P1 OR
P2. Consider a request R, and suppose that P1 has a ``permit'' for R.
Would what P2 says make a difference for the overall decision? In
other words what if P2 has a ``deny'' for R? should it be different
from the case wher P2 does not have anything for R? (if so the
composition would become much more complicated and the evaluation
process less efficient as all the policies in an expression should be
evaluated always).

There is general consensus among the people on the concall that policy
composition should operate on the decisions of the policy, not on the
rules in it. So whether P2 could have a negative response to the
request because of the absence of a ``permit'' for it or because of a
``deny'' for it should not make a difference.

--> ACTION: Everybody to submit use cases to the list with example of
    policies, so that the limitation/expressiveness of the approaches
    can be evaluated. Use cases to be submitted to the list by Friday
    Dec. 14th.





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


Powered by eList eXpress LLC