Subject: Re: [xacml-users] Policy combinations; how to preserve intended meaning...?
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 <email@example.com> 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