OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml-comment message

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

Subject: RE: [xacml-comment] Policies vs. Rules

I agree. Also the use of Target, separate from Condition allows Policy designers some control over optimization of policies.




From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
Sent: Tuesday, March 17, 2009 8:44 AM
To: Florian Huonder; Rich.Levinson
Cc: xacml-comment@lists.oasis-open.org
Subject: RE: [xacml-comment] Policies vs. Rules


The big difference between <Policy> and <Rule> is that <Condition> can appear in <Rule> but not in <Policy>.  Functions can be used in conditions but not in targets.


Logically, you could put your entire rule set into one big <Condition>, so in that sense all other XACML elements are unnecessary.  Then you would have something closer to RIF (http://www.w3.org/2005/rules/wiki/RIF_Working_Group).


The benefit of <PolicySet>, <Policy>, and <Rule> is that they allow you to arrange your rules in a way that makes business sense.  For example, if you have a contract for sharing intellectual property (IP), you can make a policy that corresponds to the contract, and rules for individual clauses within the contract.  This helps you keep track of where your rules come from.  You can code the expiration date into the policy.  If the contract is amended, you can add or delete rules easily.  If you have several such contracts, you can group them into an IP PolicySet.  This can live along side a "need-to-know" policyset and an "export compliance" policyset in a master policy set for your organization.


Just because you can reduce all rules to a normalized logical schema doesn't mean you must (or should) do so.  And the specification shouldn't require it.  A primary virtue of XACML is that it can be mapped to different arrangements of business rules.




From: Florian Huonder [mailto:fhuonder@herasaf.org]
Sent: Tuesday, March 17, 2009 04:36
To: 'Rich.Levinson'
Cc: xacml-comment@lists.oasis-open.org
Subject: RE: [xacml-comment] Policies vs. Rules

Hi Rich


Thanks a lot for your answer.


I think I did not caught on so far.


As I understood your  answer, in XACML 2.0 there is a difference between on Policy with multiple Rules and multiple Policies with one Rule each. But I did not understand it (maybe it's my English J).

I understood that in XACML 3.0 (when using the extended and recommended new combining algorithms) there is no difference between a Policy with multiple Rules and multiple Policies with on Rule each.

If that is true, what exactly would be the reason not to drop Rules?


I am looking forward to hearing from you.





From: Rich.Levinson [mailto:rich.levinson@oracle.com]
Sent: Montag, 16. März 2009 15:50
To: Florian Huonder
Cc: xacml-comment@lists.oasis-open.org
Subject: Re: [xacml-comment] Policies vs. Rules


Hi Florian,

I agree with your issue, and I believe the TC also, in principle, agrees.

This was the primary motivation behind the development of the so-called "extended" combining algorithms that are in the current XACML 3.0 draft:

These "extended" algorithms have two significant characteristics:

  • They fill a functional gap in the original algorithms, which was that the originals did not take into account the fact that if a Policy contained a set of Rules, all of which had the same Effect, then one could apply the same logic as in the original algorithms which was for Rules only, which was to incorporate this "half-boolean" property to the combining algorithm for Rules. The same logic applies, in principle, to a Policy that contains Rules that can only evaluate to one Effect.
  • This effectively makes the Policy and Rule processing indistinguishable, which allows one to assume the point you mentioned that when using these extended algorithms, there is effectively no difference between a Policy w multiple Rules and multiple Policies w one Rule each


Florian Huonder wrote:

Hi all,
I have a question about Policies and Rules.
I really do not see the reason to distinguish between Policy and Rule. In my
opinion, everything that you can solve with a Policy that has multiple
rules, can also be solved with multiple Policies (where each only has one
single Rule).
The only difference that I see between Rules and Policies are that they map
to different target sets. Meaning that a Rule maps to DENY or PERMIT and a
really do not see a practical application for this difference.
Maybe you could give me a hint about what the intent is behind Policies and
I heard that there is a requirement for Rules.
Could anybody tell me what the requirement for Rules is?

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