RE: [xacml] Re: policy model, part 1

[Tim Moses <tim.moses@entrust.com>]

Title: RE: [xacml] Re: policy model, part 1

Anne - Is your concern at all alleviated by the fact that there is a specified meta-policy, identified within the ruleStatement, that has to be identical to the meta-policy identified in all the other rules with which the rule can be combined?  This should ensure that a rule-writer can deduce what the effect of his or her rule will be.  All the best.  Tim.

-----------------------------------------
Tim Moses
Tel: 613.270.3183

-----Original Message-----
From: Anne Anderson [mailto:Anne.Anderson@Sun.com]
Sent: Thursday, February 14, 2002 9:26 AM
To: Simon Godik
Cc: XACML TC
Subject: [xacml] Re: policy model, part 1

Simon's model corresponds to Carlisle's "Sub-Model 1: The Real
Database", which I call a "Set of Rules Model".  My objection to
this model is the writer of each rule must be all-knowing: all
rules are on an equal footing, so the writer of each rule must
know exactly under which conditions that rule will apply.  It
also does not allow for delegation of policy for specific
situations.

Some enterprises may want to follow this model, but unfortunately
it is not compatible with the hierarchical, delegated policy model
that other enterprises may want to follow:

  A referenced policy is N/A if its applicability conditions are
  FALSE:

  Base Policy:
  <policy>
    <AND-omitting-N/A>
      NecessaryReferencedPolicy1,
      NecessaryReferencedPolicy2,
      ...
      <OR>
        SufficientReferencedPolicy1,
        SufficientReferencedPolicy2,
        ...
      </OR>
    </AND-omitting-N/A>
  </policy>   

A hierarchical, delegated policy model, on the other hand, can
support the "Set of Rules" model:

  A rule is N/A if any of the predicates on Subject, Action, and
  Resource is FALSE:

  Base Policy:
  <policy>
    <and-omitting-N/A>
      NecessaryRule1,
      NecessaryRule2,
      ...
      <or>
        SufficientRule1,
        SufficientRule2,
        ...
      </or>
    </and-omitting-N/A>
  </policy>

The difference is that referenced policies may in turn reference
other policies, while rules are complete in themselves.

On 14 February, Simon Godik writes: policy model, part 1
 > Note: Rules are extensible: ie we should be able to accomodate
 > provisional authorization semantics (Michiharu), deny semantics, etc.

Accommodating extensible semantics at the rule or referenced
policy level, where those semantics affect the base policy
evaluation, is incompatible with efficient hierarchical,
distributed policy evaluation.

 > Rule components.
 > The simpliest form of a subject is authenticated identity of a requestor.
 > Another simple form for a subject is a list of groups and roles.
 > In general subject is a boolean expression over subject attributes.
 > eg: user.id='foo' and user.group='xacml_tc'
 >
 > The simpliest form of a resource is a resource name. Another simple form
 > of resource is resource group name. In general, resource is a boolean
 > expression over resource attributes.
 > eg: res.owner='gates'

Having the "selector" predicates be boolean expressions over
attributes is not consistent with the requirement I have heard
that "selector" predicates be simple regular expressions that
allow fast selection of potentially applicable rules or
referenced policies.  The attributes may not be in the initial
query, and may require lookup by an Attribute Authority.

Simon's proposed syntax is still compatible with the proposal to
have expanded applicability predicates, which is compatible with
hierarchical, distributed policies.

  <applicablePolicy \>
      <resource>"simple resource match"</resource>
      <subject>"simple subject match"</subject>
      <action>"simple action match"</action>
      <fullApplicability>
           [arbitrary boolean expression on arbitrary elements
            of the request or attributes derivable from the
            request or environment]
      </fullApplicability>
      <policy>
           [arbitrary boolean expression on arbitrary elements
            of the request or attributes derivable from the
            request or environment]
      </policy>
  </applicablePolicy>

 > If both authorizations and restrictions are present in the policy (4) rules
 > are combined with a formula
 > (rs1 /\ rs2 /\ ... /\ rsM) /\ (r1 v r2 v ... rK)

 > That means all applicable restrictions must be satisfied and at least
 > one applicable authorization must be satisfied.

See my Boolean Policy example at the top.  It is exactly equivalent.

 > 2 - policy is treated as a black box and it is logically combined with
 > a rule in another policy. In this case policy is queried and result of the
 > query is used directly in rule evaluation.

I don't understand this.  How is a rule extracted from another
policy?  What "rule" is being evaluated?

 > 3 - policy is unpackaged and rules are merged directly into another policy.
 > This is policy merging. This is the most difficult option even if algorithms
 > in both policies are the same. If algorithms are different one policy should
 > be reformulated.

I don't see the difficulty if you stick with the "rules" model
where rules are either necessary or sufficient.  For each policy,
add all "necessary" rules to the <and> clause of the base policy,
and add all "sufficient" rules to the <or> clause of the base
policy.  Then evaluate.

Maybe you are referring only to policies having an evaluation URI
that has semantics other than "necessary" or "sufficient"?

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>