Re: [xacml] 2.0 and 3.0 compatibility

[Erik Rissanen <erik@axiomatics.com>]

I already found an issue with this solution. It is possible for an xpath 
to refer to elements within the <Subject> element without referring to 
the subject category xml attribute, so it would end up matching 
mistranslated subject categories and thus affecting the result.

It would probably be quite unusual to do so in a policy, but if this is 
a concern, the PDP can be configured explicitly with which attribute 
categories are subject categories and we are safe. So I still think we 
have solved the issue.

/Erik



Erik Rissanen wrote:
> All,
>
> Since the meeting earlier today, I've been thinking about the 
> backwards compatibility issue. I think I have a solution which will 
> always work.
>
> What we are aiming for is to be able to mix 2.0 and 3.0 policies and 
> requests in a single PDP implementation. There are four cases to 
> consider.
>
> The cases of a 2.0 policy against a 2.0 request and a 3.0 policy 
> against a 3.0 request are obviously not issues.
>
> Now, consider a 3.0 policy against a 2.0 request. In this case we can 
> upgrade the 2.0 request into an 3.0 request and the 3.0 policy should 
> work fine. The upgrade procedure is to simply create attribute 
> categories for the subject, resource, action, environment and any 
> particular subject categories. The resource content document goes in 
> the content element of the resource category and any xpath operation 
> in the 3.0 policy should work as long it refers to the standard 
> categories. If it does not refer to the standard categories, it won't 
> apply to the 2.0 request anyway.
>
> The 2.0 policy and 3.0 request is a bit trickier. As we have discussed 
> at length earlier, it is very difficult to upgrade a 2.0 policy into 
> 3.0 in general due to the problem of rewriting xpath expressions.
>
> However, it seems to me that it is easy to downgrade the 3.0 request 
> into a 2.0 request. Initially I thought it would not be possible since 
> the 3.0 request is more expressive than the 2.0 request, but it turns 
> out it doesn't matter.
>
> What we do is that we create a 2.0 request from the 3.0 request as 
> follows: From the standard resource, action and environment categories 
> in the 3.0 request we create the resource, action and environment 
> elements of the 2.0 request. The remaining 3.0 attribute categories 
> all go into the subject element as subject categories.
>
> The treatment of the resource, action and environment should be clear. 
> But what about all the categories which could mistakenly be made into 
> subject categories? There are two cases to consider:
>
> 1. The 2.0 policy refers to the 3.0 category.
> 2. The 2.0 policy does not refer to the 3.0 category.
>
> In case 1, this can only happen if the 3.0 category is actually a 
> subject category, so this means we have made a correct translation.
>
> In case 2, the mistranslation will not have any effect on the decision.
>
> Anyway, please review my thinking. It's midnight here now and I am up 
> only because I cannot sleep due to excess caffeine intake earlier 
> today. I might have missed something here. :-)
>
> Regards,
> Erik
>