OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: [xacml] Boolean Policy resolution - a slight modification


Title: RE: [xacml] Boolean Policy resolution - a slight modification

I have been thinking about two problems with this proposal and I would like to suggest a slight modification which I think solves them, at least mostly.

1. The problem I identified at the meeting, is that if policy creators and their repositories are scattered about and operate independantly, it will be impractical for the base policy to accurately track the specific file names of files containing policies pertaining to specific targets.

2. In any case, even when all the policies are in a single location, I would expect to maintain multiple policies that have overlaping targets. This is the way our product works today and people seem to find this an intuitive way to describe the policies that they wish to express. Even when they are all in one place, I cannot combine them in advance of evaluation for a couple of reasons.

First of all, when the admin comes back to modify the policies, he or she is going to expect to see the policies they previously created, not a mathematically equivalent policy. The same goes for a "what-if" tool that displays policy evaluation results and attributes the decisions to specific policy elements. Of course, I could keep the original policies around, but I think this would greatly increase the risk of various kinds of errors.

Second, because of our goal of keeping the target expression simple, we do not have the power to express the resulting combined policies. For example, consider two policies with partially overlapping target mappings. I assume it is impractical to enumerate all the target values. So one of the new combined policies would have to have a target of "all of X minus all of Y" which we do not permit, I think correctly.


So here is my scheme. Let's generalize <applicablePolicyReference> a little. It is already a URL, so I can define an XACML policy retrieval protocol that returns all applicable policies that might match the target value of the current request. All I need is some syntax to allow me to pass the target value as an argument. I don't know what the XML would look like, but in concept I want to say:

<applicablePolicyReference>
    xprp://policy.sample.com/$TargetValues
</applicablePolicyReference>

where xprp is an XACML policy retrevial protocol and $TargetValues means the runtime target actuals are passed as part of the call.

Since this can return multiple applicable policies, I further propose that the surrounding combinator treat each returned applicable policy as if it were a distinct predicate. In other words (Polar should like this) this:

<and>
    <applicablePolicyReference>
        xprp://policy.sample.com/$TargetValues
    </applicablePolicyReference>
</and>

means that value of each applicable policy returned is anded with the others (and any other retrevial points with in the combinator), as usual dropping the ones that turn out to be inapplicable.

As far as I can see this solves both problems. If I have all my policies cached locally, the base policy still correctly expresses their relationships and I don't have to resort to some kind of ad hoc, built in rule for combining them.

The only problem I see with this is that while it works fine for AND and OR, (which is all I really care about) there are issues with some combinators, such as N-OF. Personally I would be happy to keep semantics of these as proposed by Anne, but this might be confusing in practice.

What do you think? Is something like this feasible?

Hal



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC