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] | [List Home]


Subject: Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)


Hi Steven,

Sorry about the slow response to this.

As I see it, there are two benefits to the category prefixing:

1. A policy can be mixed admin/access.

2. We don't need to change the XACML evaluation logic as much. To implement the delegation model, the PDP can use the normal XACML evaluation on admin requests, while building the delegation graph.

I think the second is a significant benefit. It would significantly complicate both the administrative spec and the implementation if we need to define additional modes of XACML policy evaluation.

What about changing the prefix so it works with all cases? Or changing the admin category to something else than it being based on a prefix? By means of some other kind of algorithm, or maybe an explicit table?

Best regards,
Erik


On 2012-09-03 07:03, Steven Legg wrote:

Hi Erik,

On 1/09/2012 1:23 AM, Erik Rissanen wrote:
I don't think we change the delegation model in this way since it would mean changing the core schema, which
we really don't want to do at this stage.

I originally suggested an XML attribute for the label, which would need
a change to the core schema, but there is another way to label the
policies without changing the core schema and that is substitution
groups for Policy and PolicySet. For example:

    <xs:element name="AdministrativePolicy" type="xacml:PolicyType"
                substitutionGroup="xacml:Policy"/>

    <xs:element name="AdministrativePolicySet" type="xacml:PolicySetType"
                substitutionGroup="xacml:PolicySet"/>

In a way this is better than a simple XML attribute because it is more
visually distinctive. It would be desirable for AdministrativePolicy
and AdministrativePolicySet to be in the same namespace as Policy
and PolicySet, but if they have to be in their own namespace so be it.

> Also, I think we did consider labeling policies like this in early
stages of the delegation work. I don't remember right now why we did not go that way, but I suspect there
was a reason.

I've found and reported on a bunch of problems with category prefixing,
so there are reasons to reconsider using labelling. If the purpose of
the prefixing is just to ensure that administrative policies aren't
applicable when evaluating access requests, and vice versa, then
labelling is a simpler and cleaner way to achieve the same end.

> Probably that the current mechanism is more flexible.

It's more flexible in that it allows hybrid policies that are a bit
access policy and a bit administrative policy. I can't think of a
good reason to want to do that, and in any case, it is always possible
to split a hybrid policy into a pure access policy and a pure
administrative policy. I would happily forego this dubious flexibility
to get rid of category prefixing and its problems.

Regards,
Steven





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