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 Erik,

On 31/10/2012 11:35 PM, Erik Rissanen wrote:
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.

How is that a particular benefit when any such mixed policy (or policy set) can be
rewritten as a pair of a pure access policy and a pure administrative policy, together
having exactly the same effect ? A policy that authorizes itself is pointless, and
merging an access policy with an administrative policy that authorizes unrelated
access policies is weird and confusing, so why do it ?

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.

The delegation model is already a significant departure from normal XACML evaluation,
what with building the delegation graph and forming administrative requests. Those
things would still be there. The complexity trade off is between category prefixing
(which is not yet complete because it has unresolved issues) and a simple boolean
test during request processing to see if the kind of the policy matches the kind
of the request (i.e., access versus administrative). That test is simple and efficient
compared to category prefixing.

What about changing the prefix so it works with all cases?

The only thing that comes to mind that would be syntactically valid is a
prefix to the scheme name. For example, http://example.com/foobar becomes

> Or changing the admin category to something else
than it being based on a prefix?

That's difficult without making changes to the core syntax.

> By means of some other kind of algorithm, or maybe an explicit table?

Labelling the policies would be much easier than a managing a mapping table.


Best regards,

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"

    <xs:element name="AdministrativePolicySet" type="xacml:PolicySetType"

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.


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