[xacml] RE: policy model, part 1

[Carlisle Adams <carlisle.adams@entrust.com>]

Title: RE: policy model, part 1

Hi all,

Many thanks to Simon for writing up his view of the policy model -- his thoughts are now much clearer to me!  I'm feeling optimistic because I don't think that the various views floating around the TC are that far apart.

I'm trying to put together a model that reconciles Simon's thoughts (which are based, at least in part, on work by Michiharu, Pierangela, and Ernesto) and what's in the v0.9 draft, but before going to XML syntax I'd like some confirmation that we can reach consensus on the main features.  So, some feedback on the following proposal would be welcome.

Carlisle.

A RuleStatement contains the following items.
  - a RuleCore, which is a triple ("subject", "action", "resource"), although one or two of the components may be missing (meaning "any").  The syntax would essentially be "RuleType" (that is, each component is a PredicateExpressionType), but in practice we would expect that the expressions used would be fairly simple ones.

  - a Condition, which is a combination of predicates that must evaluate to true for this rule to fire.  The syntax would essentially be PredicateExpressionType and may be arbitrarily complicated.

  - an Effect, which says how this rule is expected to contribute to a policy result.  The syntax would essentially be EffectType, but extended to include another enumeration.  The possibilities are

        - "Permit" (Simon's "authorization" rule which, if TRUE, will contribute to a "Permit" decision but if FALSE may not cause a "Deny"),

        - "RequiredPermit" (Simon's "restriction" rule which must be TRUE before a "Permit" decision can be returned and if FALSE will force a "Deny"), and

        - "Deny", which, if TRUE, will cause a "Deny" decision to be returned.

A PolicyStatement contains the following items.
  - an Identifier, so that it may be referenced.
  - a Name (optional).
  - a Comment (optional).
  - perhaps some other items (e.g., Issuer, or IssueInstant), even if these might also be part of the SAML assertion envelope (see MetaPolicyStatement below...).

  - a Target, which specifies the applicability of the policy.  The syntax would essentially be RuleType.  Each component (i.e., "subject", "action", "resource") is, in the worst case, the union (i.e., the "or") of the corresponding components in the included RuleCore or Target expressions, but in many cases a simpler equivalent expression may be found.

  - a Policy.  There are four possibilities for this:
        - a "basic", "independent" policy
        - a "basic", "dependent" policy
        - a "compound", "independent" policy
        - a "compound", "dependent" policy

Definitions:
  - a "basic" policy is a combination of rules;
  - a "compound" policy is a combination of policies (this is what we've called a "base policy" or a "higher-level policy" in the past, but "compound" may be more intuitive...);

  - an "independent" policy explicitly includes the combining algorithm and therefore can be evaluated entirely on its own;

  - a "dependent" policy points to (i.e., references) an external, generic combining algorithm (a metapolicy) and therefore can be evaluated only in conjunction with that metapolicy.

A MetaPolicyStatement contains the following items.
  - an Identifier, so that it may be referenced.
  - a Name (optional).
  - a Comment (optional).
  - an Algorithm for combining predicates, which may be predicates about rules (such as "Permit" and "Deny") or predicates about policies (such as "Issuer" or "IssueInstant").  The syntax would essentially be PredicateExpressionType.