Re: [xacml] What I learned from yesterday's telecon

MHonArc v2.5.2 -->

xacml message

[Date Prev]
 | [Thread Prev]
 | [Thread Next]
 | [Date Next]

--

[Date Index]
 | [Thread Index]
 | [Elist Home]

Subject: Re: [xacml] What I learned from yesterday's telecon

From: Simon Godik <>

To: Tim Moses <>, 'XACML' <>

Date: Tue, 26 Feb 2002 12:18:38 -0800

Title: What I learned from yesterday's telecon

[Tim] 1. A policy is the complete combination of 
rules governing access for a particular authorization decision request.  A 
policy will often be too complicated for a human to work with it, in toto, 
directly.

This is 'applicable' policy. A policy is a set of rules + metapolicy.

[Tim] 2. A rule is the largest fragment of policy that a 
human can work with directly.  Yes, the definitions are circular and, in 
the case of "rule", vague.  Of course, there is no objective way of telling 
whether a fragment of policy is too big for a human to work with directly or 
not, but existing work suggests that a triple, containing a definition for 
resource, action and subject, fits the definition.

I do not think that there is agreed upon definition of a rule in the 
grlossary, but informaly (positive) rule states that Subject S is allowed to 
perform action A on resource R if conditions C are satisfied. It translates into 
triplet-like xml syntax.

[Tim] 3. A rule will often mimic the administrative GUI 
in which policy is written and analyzed.
4. A rule is an 
artifact entirely internal to the administrative system.

A rule is internal to the policy. Policy could be put into admin 
framework.

[Tim] 5. A policy is an artifact visible external to the 
administrative system.
6. In many cases, policies will actually 
turn out to be a set of rules combined in some relatively simple way, according 
to one of a few common meta-policies.

Agree, (6) is actiually a definition of a policy (without the word 
'simple').

[Tim] One camp argues that rules should be 
reflected in the syntax of the language.  Another camp says, the syntax of 
the language should be perfectly general.  Then it will be possible, but 
not necessary, that a policy be constructed from sets of triples combined in 
some simple, prescribed, way.  But, it will be up to implementations of 
policy-writing software to determine what the form of a policy will actually 
be.  Both arguments have some appeal.

In the first case, it may be practical for 
developers to write and read policies directly in the language.  This, at 
least will help with debugging the tools that others will use to manipulate 
instances of the language.  However, I wouldn't expect a policy 
administrator to work directly with XACML instances.  On the other hand, 
can we really be confident that limiting policies to be simple combinations of 
triples will be sufficiently general for all our uses?

Personally, I like the idea that a general logical 
combination of predicates or references to other policy instances would be a 
valid XACML instance.  Implementations can always build their policies in 
the form of triples combined by simple logical formulae, if they wish, and these 
would be valid XACML.  But, the language wouldn't limit us to this 
approach.  Naturally, administrative GUIs would hide the details of XACML 
instances from administrators; quite possibly presenting it in the form of "rule 
triples".  But, PDPs would be built to process arbitrarily-complicated 
combinations of predicates.  The general predicate type could be extended 
to provide sub-types for resource predicates, subject predicates, 
etc..

In informative material, we can provide guidance 
to implementers on how to produce a policy based on rule triples with "grant", 
"deny" and "only_if" effects.

It would certainly be possible to specify a syntax 
for a rule, as well.  But, this doesn't serve any interoperability 
goal.

Of course, limiting policies to the combination of triplets would not be 
sufficient. For that xacml rule structure should be made 
extensible. Extensibility of rule structure is similar to 
extensibility of predicate types. Because if you take a 
structured rule and smash it with a hammer, all the pieces will carry their 
initial semantic meaning in the types of predicates. 

Even with general predicate syntax some structure is needed. We already have 
<target> element with <subjects> and <resources>. So predicate 
expressions that define applicability of a rule should be placed there, 
otherwise we do not need <target>. For example, suppose a rule says that 
administrators can read configuration file. Resource predicate expression 
req.resource=config.dat will go under <resources> and subject predicate 
expression subj.role='admin' will go under <subjects>.

Resource definition also needs structure, so that member-of an instance, 
member-of a class semantics are clear.

If we adopt general predicate expression structure, it should have enough 
information in it so that triplet form could be reconstructed. If we adopt 
simple syntactic shortcuts this general form will look like a triplet.

Simon