Re: [xacml-users] Policy combinations; how to preserve intended meaning...?

[argyn <argyn@cox.net>]

blair bethwaite wrote:

> Hi again,
>
> Here's a brief example to help illustrate the type of access
> management scenarios I am trying to cater for.
>
> On 10/19/06, argyn <argyn@cox.net> wrote:
>
>> bring the examples, then people would be able to help you.
>
>
> for example, all objects in the repository are open access by default,
> a collection of objects may be restricted to postgrads only, except
> for a particular group of undergrads, however there are culturally
> sensitive images in some of the datastreams(data components of the
> object) that are restricted to subjects of certain ethnicity or tribal
> affiliation.  Clearly in this scenario you want each policy to be
> applicable over different domains in the repository, however
> specifying all these different policies using the default setup would
> cause Fedora to find all the applicable policies for a request and
> combine the evaluation results using DenyOverrides - disregarding the
> intended effect of the various policies.  

you can build a complex combination of policy sets with not only 
denyoverrides but other algorithms, e.g. the denyoverridesd policyset 
would contain other policysets with other algorithms. also, you can use 
policy targets to improve performance. they can be indexed and are 
supposed to be evaluated first. so, if you have thousands policies, you 
can use their targets to find applicable ones quickly.


> This is where the
> first-applicable PolicySet for each object I described in my initial
> post is useful.

i am not super excited about this approach. fist applicable algorithm is 
kind of strange to me. i never used it myself. i prefer unordered 
algorithms, they are easier to understand and manage, imho

>
>> xacml can handle policy hierarchies. the question is how to construct 
>> them most
>> effectively
>
>
> Yes, I'm aware that XACML can do policy hierarchies however from what
> I've managed to digest so far it seems that sunxacml doesn't have
> explicit support for the hierarchical resource profile (as defined by
> XACML 2.0), and neither does the Fedora PDP/PIP implement a
> ResourceFinderModule capable of handling resource hierarchies as
> discussed in the sunxacml programmer's guide.

that's true, imho

> Besides all this I
> don't even think the hierarchical resource profile would be useful for
> Fedora as any hierarchy you can conceive would only be three or four
> levels deep and perhaps more importantly the APIs(read actions in
> XACML) are setup explicitly to provide access at different points of
> the object model.

one option is to implement hierarchical resources. i found it easier to 
use groups. your user would belong to groups and hierarchical resource 
ids. for instance, you can have groups like "east" and "west". your 
resources would be urns like "/east/flags/home" or "/west/secret/stay", 
then your policies would have regexp resource matchers in targets like 
"east", so whatever resource id starts with "east" would use this policy 
to manage the access. you can add the subject matcher too. this way you 
dont have to deal with hierarchical resources, and it's not that bad in 
performance. you can implement your own custom finder which does 
matching fatser than the stock finder module. i've done something like 
that with one web application, where my resources where hierarchical in 
nature, such as screens and menu items.

thanks
argyn