Policy combinations; how to preserve intended meaning...?

["blair bethwaite" <blair.bethwaite@gmail.com>]

Hi Everybody,

I'm working for Australian Research Repositories Online to the World
(ARROW), http://www.arrow.edu.au/, in conjunction with a group at
Monash University interested in constraint logic programming (CLP).
My project involves developing a prototype to help with policy
administration, the idea is that the prototype will use CLP in order
to be able to reason more effectively (and naturally) about rule
interaction.

ARROW repositories are based on Fedora (for the uninitiated: Flexible
Extensible Digital Object Repository Architecture), www.fedora.info.
Fedora 2.1 added support for pluggable XACML based access control with
Fedora providing the key parts of the XACML workflow using Sun's
implementation of the standard.  This means that my prototype will
need to output its policy/rule database in XACML that can be read into
Fedora.

Now, onto the main point...

The examples I have from ARROW indicate that they want to be able to
specify policies at multiple levels, and the reason for my project is
that they are concerned about keeping things consistent.  They need to
be able to specify broad policies that apply to a whole repository,
policies that apply to some subset(large and small) of the resources
or users/subjects of the repository (such as all theses, all
undergraduates, all resources with pdf components, working group X),
policies that apply to particular resources or subjects, and policies
that apply to sub components of a resource (datastreams in Fedora).
Hopefully even from this basic description of their needs you can see
that there will likely be several policies that apply to every request
and overlap between the sets that policies apply to, meaning that the
XACML policy combination algorithm chosen becomes quite important.

As I thought about this further I realised two things.  Firstly; that
it would be likely that different policies applying to each request
would result in a mixture of allows and denials, and secondly; that in
these cases it wasn't yet clear what should prevail.  Initially the
idea was to go with DenyOverides, however after looking at some
examples it seemed that this would not preserve the original intention
of the policy specification - the reasoning being that if you have
several policies applying to a particular request it is probably the
most specific (with respect to the resource and subject attributes)
that you want to apply, and it turns out that ARROW thought this was
the right idea too.

This is where I came up with the idea for a policy combination
hierarchy, it will be simple enough for my logic program to determine
what level of specificity each rule has and favour the most specific
rule/s possible when testing its rules against a particular request
(using simple DenyOverides when there are multiple matches at the same
level).  However, the rules need to be exported to XACML which will be
enforced externally and so the meaning must be preserved somehow using
XACML policy combination.  So essentially what I'm asking is, does
anybody have any suggestions or caveats about how I should do this or
whether you think the method I outline below will work...

I'm not keen on getting familiar enough with XACML to write my own
policy combination (a day or so reading over the core spec is quite
enough), plus I think this sort of thing must be common enough that it
should be possible with the predefined combinations.  The best way I
see to do this with the predefined combinations is to use a top level
<PolicySet> that applies to everything and compose it of
<PolicySetIdReference>s to <PolcySet>s that match each of my
specificity levels.  The <PolicySetIdReference>s would be listed in
order from most specific to most general and combined using
first-applicable.

Any comments?

Cheers,
-Blair

-- 
In science one tries to tell people, in such a way
as to be understood by everyone, something that
no one ever knew before. But in poetry, it's the
exact opposite.
 - Paul Dirac