[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, whichwe 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 earlystages of the delegation work. I don't remember right now why we did not go that way, but I suspect therewas 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