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] Questions and Clarifications on the Concall


On Tue, 12 Feb 2002, Carlisle Adams wrote:

> [snipped for brevity]
>
> So now I really don't understand the difference between "policy" and "rule".
> How are they different?  Do we need to distinguish between them?  Do we need
> separate syntax for them?  Why not forget about rules altogether and say
> that, for XACML, a logical combination of predicates, with a (possibly
> simplified) applicability or target element, and with an explicit grant/deny
> indicator, *is* a policy.  No mention of rules whatsoever (except possibly
> in the "Related Terms" section that follows the glossary).

I don't understand the difference between policy and a rule either if you
want to "compose" policies in a general fashion. Composing policies is
good thing, as it leads to reuse, i.e. policy libraries, etc.

I had thought that a we were working on a logic to compose general
predicates. The "applicablePolicy" is just a general predicate with a
little more structure, namely the applicability premise. But it is still
is first and foremost just a predicate in a 3 valued logic of true, false,
and inapplicable.

The one thing that is missing for a PDP. With the options that a PDP is
supposed to return, e.g. Permit, Deny, and Indeterminate:

1. To what does true map?
2. To what does false map?
3. To what does inapplicable map?

In most cases it would be up to the administration of the PDP. Most likely
candidates are:

True         -> Permit
False        -> Deny
Inapplicable -> Administrative Default of Permit, Deny, or Indeterminate

To gain consistency with Policy Writers, they should have the notion that
if their policy evaluates to true it will map to Permit, false to Deny,
and inapplicable means that they are not concerned and the resultant
policy is left up to a higher level (either by composition with other
higher level policies, or the PDP administrative default).

If you take the "rule" route, you will need specific 2 valued logical
predicates (T,F). These predicates will most likely be predicates
comparing values only.

You will need "rules" which are specific maps of predicates to Permit,
Deny, and Indeterminate. In this case, the rules are constructed with an
ordered if-then-else strategy, and taking the first Permit or Deny. If a
rule evaluates to Indeterminate, then you go to the next rule. Any other
evaluation strategy will result in possible conflicts (i.e. one rule
returning Permit and another Deny).

This strategy is exactly the strategy I used in my Access Control Language
for CORBA, SAL.
http://www.omg.org/news/meetings/workshops/presentations/docsec_present/2000/sal-ws1.pdf

If you want to compose policies in arbitrary ways, (which is what I
thought we were doing) it is better to go with the above approach, using
True, False, and Inapplicable, using logical connectives such as AND, OR,
etc. to resolve conflicts of True, False in a logically sound way, then
finally mapping to Deny, Permit, Indeterminate at the PDP administrative
level.

Instead of the if-then-else "rule" strategy, you can do the same with
conflict resolution operators on the Permit, Deny, Indeterminate values,
such as "ALL-MUST-PERMIT", etc.

There are trade-offs on each strategy. With the "rule" approach, policy
writers have some notion of whether they are actually Permitting or Denying
access, (Although if their policy is composed within some other policy,
they'll HAVE NO IDEA what is actually going to happen).

With the "general logic" approach, you can avoid such things as
duplication of predicates in rules, which can cut down on evaluation time.
The downfall is that the policy writer doesn't really know if true really
means Permit. (Which by the way, is the same situation the policy writer
is in above anyway.)

I can go either way.

Cheers,
-Polar




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


Powered by eList eXpress LLC