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,

See inline.

On 2012-11-05 05:42, Steven Legg wrote:

Hi Erik,

On 1/11/2012 6:40 PM, Erik Rissanen wrote:
Hi Steven,

I do think there is some practical value in being able to collect any types of policies into a single policy set, but I agree that the value probably is not that big. In come cases where someone would hand over a policy set "here are all my access and admin policies", they would have to hand over two separate sets of
policies instead.

And, yes, when I think about it more, the evaluation logic change is small. And there is actually one additional benefit. The explicit marking of a policy as an admin policy is probably simpler conceptually to
users than to use weird attribute category names.

I agree completely.


So, I would agree with you to these changes.

Reflecting on what you say here and what you were saying during the TC
meeting makes me think you are assuming more than the minimal change
required to dispense with category prefixing, in which case there are
some technical choices to be discussed. I'll start by describing the
minimal change.

The reduction procedure, as currently described by the administration
profile, begins when the PDP encounters an applicable, untrusted access
policy. Let's call it 'A'. A reduction graph is formed by considering
each ordered pair of policies in the policy set that contains 'A'. Let's
call that policy set 'B'. To even get to the point of evaluating access
policy 'A', policy set 'B' must be an access policy set (which is to
say, it has a target that can only be satisfied by an access request).
For policy 'A' to be authorized at all there must be at least one sibling
policy of 'A' that is an administrative policy. Let's call it policy 'C'.
So an access policy set like 'B' must be allowed to have children that
are either access policies (like 'A') or administrative policies (like 'C').
In the current scheme we distinguish between access policies and
administrative policies by whether or not they have attribute designators
referring to prefixed categories. In the new scheme we would tell the
difference by the element name of the policy, e.g., either <Policy> or
<AdministrativePolicy>, and in the process exclude the unhelpful
possibility of hybrid policies.

It is also possible for a sibling of policy 'B' to be an administrative
policy set, which is to say, a policy set with a target that can only be
satisfied by an administrative request. We can likewise distinguish between access policy sets and administrative policy sets by the element name, e.g.,
either <PolicySet> or <AdministrativePolicySet>. Let's say we have an
administrative policy set 'D' that is a sibling of policy 'A'. Both policy
'C' and policy set 'D' are considered when reducing policy 'A'. In which
case they are evaluated with respect to an administrative request. Policy
set 'D' is only ever considered when processing an administrative request,
so any access policy or access policy set children of policy set 'D' will
never be evaluated. We might as well disallow such children.

In summary, what we have for the minimal change is <PolicySet> elements
that may have <Policy>, <AdministrativePolicy>, <PolicySet> and
<AdministrativePolicySet> children, and <AdministrativePolicySet> elements
that may have only <AdministrativePolicy> and <AdministrativePolicySet>
children.

The fact that an access policy set can have administrative child policies
and policy sets is a non-issue for most policy set combining algorithms.
In the current scheme the administrative children would always evaluate
to NotApplicable when evaluating an access request. In the new scheme the
administrative children would be skipped (or automatically NotApplicable)
when evaluating an access request. Either way, the result of the combining
algorithm is unaffected. The one exception is the on-permit-apply-second
combining algorithm because it limits a policy set to exactly two children.
If, for an access policy set, those children are both access policies,
then in practice they have to be trusted policies because there is no room
for any administrative policies to authorize untrusted policies (note
this is also the case with the current administration profile). If either
child of an access policy is an administrative policy, then the policy set
will never be applicable. To make the on-permit-apply-second combining
rule more useful in an administrative setting, the restriction to two
children should be relaxed to two access children and any number of
administrative children when the combining rule is used in an access
policy set. The "first" and "second" children should be taken to mean the
first and second access children, or we can insist that any administrative children must come after the two access children. What to do in the case of an administrative policy set with the on-permit-apply-second combining rule
is not so obvious. If we limit it to two administrative children, then
those children would have to be trusted in practice. We could say that
the first two children are considered by the combining algorithm and any
subsequent children are only used if reduction of untrusted children is
required.


I think the above "minimal change" seems good. I don't think it is a big problem that the on-permit-apply-second is meaningful only in context of trusted children, since it is intended to solve the issue of a condition in policies, and for that purpose everything work fine.

That covers the minimal change. The more substantial change is a complete
separation of access and administrative policies and policy sets. That is,
a <PolicySet> can only have <Policy> and <PolicySet> children, and an
<AdministrativePolicySet> can only have <AdministrativePolicy> and
<AdministrativePolicySet> children. An access request would initially be
assessed against the collection of access policies and access policy sets. The administrative policies and policy sets would become involved if there are any untrusted access policies or policy sets to be reduced. A revision
of the reduction procedure would be necessary and I see two main
possibilities.


I don't like the above since this introduces a top level construct in the PDP which is different from any of the regular XACML policy constructs. It is a fact that the initial request to the PDP is an access request, so the access request must match the "top level policy construct" in the PDP. Also, if the administrative profile is going to be of any use, this top level policy construct also has to also be able to contain administrative policies. Thus the top level policy construct is something different from the above policy constructs which you listed.

That adds more specification and implementation cost, compared with a PDP which simply starts with a selected top level policy set, which is semantically no different than any other policy set in XACML.

The first possibility is that we keep the idea of a reduction graph, only
instead of the nodes in the graph being the siblings of the untrusted access policy being reduced, the nodes are the standalone administrative policies
and policy sets. In effect, every access policy has every standalone
administrative policy or policy set as an implied sibling when forming the reduction graph. We have the choice when reducing an untrusted administrative policy whether to consider the actual siblings of that administrative policy
when forming the reduction graph (call this (1.a)), or to form the graph
from the standalone administrative policies and policy sets (call this (1.b)),
just as we would for untrusted access policies.

The second possibility (call this (2)) is to do away with the reduction
graph and simply assess an administrative request against the collection
of administrative policies and policy sets just as we assess an access
request against the collection of access policies and policy sets. If we
find an untrusted policy (in either collection), then we form the
necessary administrative request and assess it against the collection of
administrative policies and policy sets.

An effect of options (1.b) and (2) is that in the process of reducing an
administrative policy we may encounter that very same administrative policy. If we do, then we treat it as NotApplicable rather than recursively reducing it. To do otherwise would open the possibility of self-authorizing, untrusted
policies. Note that this effect doesn't arise with the delegation graph
because policies aren't paired with themselves.

Also with options (1.b) and (2) we don't need to do anything about the
on-permit-apply-second combining rule. Administrative policies no longer
need to be siblings of the untrusted policies they authorize, so the
on-permit-apply-second combining rule can still insist on having exactly
two children.

I would very much like us to choose option (2) because working out where
to put an administrative policy under the current scheme is a burden policy
writers can do without. Take the simple case where User A delegates all
rights to User D. This is a very simple administrative policy that basically says "if the delegate is User D, then Permit". The issue is where to put it. User A needs to place it (by copy or by reference) in every policy set where
User D will potentially be creating access policies. Furthermore, as new
policy sets are created that User D might put policies into, User A will have
to put the administrative policy in there as well. Conversely, if User A
isn't thorough or proactive in placing the administrative policy, then User D will be limited in the rights he or she can actually exercise. Compounding
the difficulties is the fact that in the general case, because of
multi-valued attributes and augmentation of the delegate category by
a context handler, practially any untrusted policy can be authorized by any
administrative policy. It all depends on the request context. It is only
by making assumptions about certain attributes being single-valued or by
knowing about correlations between the attributes of an access subject that
we can begin to predict which untrusted policies will be authorized by
which administrative policies in the absence of any specific request context. These are things that users shouldn't have to be concerned with when creating administrative policies. Options (1.b) and (2) mean that they don't have to be. Option (2) is the conceptually simpler of the two, and can simulate (1.b)
if desired.


I don't agree that option 2 is simpler conceptually. I would say it's the opposite since it introduces another type of policy combining at the top level.

Also, being able to mix in admin policies in nested access policies is useful for creating hierarchical structures, where a delegated policy contains nested delegation itself. This sort of recursion is useful for being able to import a full policy set of a sub-organization which internally might want to use delegation.

Best regards,
Erik

Regards,
Steven


Best regards,
Erik


On 2012-11-01 06:14, Steven Legg wrote:

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
delegated-http://example.com/foobar.

> 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.

Regards,
Steven


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]