xacml message

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

From: Steven Legg <steven.legg@viewds.com>
To: Erik Rissanen <erik@axiomatics.com>
Date: Thu, 24 Jan 2013 17:36:53 +1100


Hi Erik,

On 20/12/2012 8:26 PM, Erik Rissanen wrote:

Hi Steven,

Ok, so in your proposal there is no reduction graph. Early working drafts of the delegation profile were
like this, so you are suggesting that we revert back to that old model.


Well, something like it I suppose. I haven't seen the early drafts.


The TC introduced the reduction graph because there are issues with the model you propose. The main reasons
the TC moved on from the model you propose were (if I recall it correctly):


A case of the cure being worse than the disease :-).


- We did not want to have the concept of a negative administrative authority, that is, someone can deny
someone else to authorize an administrative request. I am not talking about combining policies and rules
within an administrative policy(set) since this is just a matter of defining the scope of the administrative
policy using XACML constructs. The problem is how to combine administrative policies from multiple authors,
which might conflict. The way the reduction graph now works it simple and well defined.


For delegates to interfere with each other's authorizations they need to
have been given authority over the same scope. Having two or more people
independently administering the same scope is asking for trouble anyway.
I had concluded some time ago that the administration profile didn't have
a good way of handling this situation and that one shouldn't go there.
If two or more people are given authority over the same scope then they
need to be cooperating, in which case there isn't a problem. A better idea
is to arrange that those people have the same issuer identity so that they
jointly own all the policies for the common scope, which is analogous to
the situation for all the people that are permitted to manage trusted
policies.

But if you want to assume independent administrators for the same scope
and only allow them to permit authority, then a new attribute could be
added to the delegation-info to give control over whether deny administrative
policies are authorized.


- You have to deal with indeterminate values from both access policies and admin policies. This is not so
simple if the policies themselves are not trusted with certainty. For instance, someone who puts an
indeterminate policy at the top level could cause interference.


An untrusted policy has no effect if there is no administrative policy that
authorizes it, regardless of where it might be, and a PAP shouldn't be allowing
just anybody to create trusted policies. The danger is if the PDP gets an error
without being able to tell whether the policy is trusted or untrusted. It is
easy for the PDP to guard against that by only accepting policies that are valid
according to the XML Schema. And PAPs shouldn't allow schema-invalid policies
to be created either, for extra safety.

In any case, the reduction graph doesn't solve this potential problem. It only
constrains the scope within which it is a problem. If administrative policies
are near the top level, which would imply that untrusted policies can appear
there too, then the scope hasn't been constrained by much at all.

If an untrusted policy evaluates to indeterminate and there is an administrative
policy that authorizes it, then the delegate is operating within the scope
of authority given to them, for good or ill. We can't legislate against stupidity.


- The reduction graph search is also computationally efficient. Some forms of the early delegation model
were NP-complete, but that was due to the ability to restrict more than one step in the delegation chain. I
am not sure if there are any issues with your proposed model though.


I'm not changing anything about how authority is established, only where the
PDP looks for authorizing policies and combines them. As it stands at the moment,
I find that I have to put a copy of each administrative policy in just about every
policy set because it isn't generally possible to determine which administrative
policy will authorize which access policy without reference to a specific request
context. That means that just about every administrative policy is considered
as a candidate during every reduction attempt using the reduction graph, regardless
of where it happens. Evaluating administrative policies from the top means that
in the worst case every administrative policy is still a candidate for consideration
during reduction, but at least they won't be duplicated all over the place. In
practice I think the search will be improved because the targets on administrative
(or hybrid) policy sets will allow large numbers of administrative policies to be
disregarded during the search. Indexing of the administrative policy sets will
also allow some proportion of them to be ignored without even getting to the point
of checking their targets.

Regards,
Steven


/Erik


On 2012-12-20 07:22, Steven Legg wrote:


Hi Erik,

On 20/12/2012 3:43 AM, Erik Rissanen wrote:

Hi Steven,

On 2012-12-19 06:29, Steven Legg wrote:


Hi Erik,

On 19/12/2012 2:08 AM, Erik Rissanen wrote:

Thanks Steven,

Ok, so the difference which I had not noticed in your proposal is that you advocate that any admin request
should always start from the top,


You need to read more carefully. That was the fifth time I'd said it.

> while I say that the reduction graph is formed within the nested policy

set like before, except of course that we use labeling rather than categories to differentiate between
admin
and access policies.

By doing nested reduction graphs, there are two benefits as I see it:

- You don't need hybrids.
- Someone can neatly package a complete policy set with nested admin policies in full, without having
to be
concerned about how this might interfere with any other "top level" policies.

Could you refresh my memory again as to why you want to start reduction from the top? What are the
benefits?


I previously said this on the topic:

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

In the current scheme an administrative policy can only authorize an untrusted
policy that is a sibling or a sibling of an ancestor. This is a severe limitation
when the scope of an administrative policy is wider than any one of the untrusted
policies that it authorizes.


It is correct that the admin policy has to be a sibling in the current scheme, and my proposed labeling
scheme. I don't see this as a major issue, rather I find it nice, because it means that this allows
recursive nesting of policies, which will not interfere with each other.


That is still possible with HybridPolicySet and evaluation from the top. The only
difference between the original access request and any administrative requests
subsequently spawned from it because of untrusted policies is that the administrative
requests will have added categories for delegate and delegation-info. If the targets
of the HybridPolicySet and its ancestor HybridPolicySets don't reference these
categories (and there is no good reason for them to do so), then a PDP evaluating
an administrative request will find its way back to the same HybridPolicySet where
the untrusted policy was encountered. If the policy set hierarchy is constructed
such that policy sets don't interfere with each other with respect to access requests,
then they won't interfere with each other with respect to the corresponding
administrative requests.

Mostly I find that I want to put the administrative policies higher up in the policy
set hierarchy, because they have a wider scope.


I don't understand your second concern in the text you quoted above. It is true that XACML policies are
written with a set of possible request contexts in mind. An admin policy can use any attributes it desires
to constrain its applicability in any way, so it is quite clear which requests it will authorize for which
delegates. It is true that the support relation between an access policy and an admin policy is resolved at
runtime, so the links are not static. A policy may support another or not, depending on the
situation/context. However, this is a feature, not a bug, since it allows an access policy author to
"consolidate authority", that is he can write an access policy which is in itself greater in scope than any
individual admin policy which authorizes him. Depending on the situation, the access policy would be
supported by different admin policies.


That feature is not something I'm proposing changing. The limitation that
authorizing administrative policies have to be a sibling or descendant of
a sibling is just not in harmony with it. If a writer of an untrusted access
policy doesn't know for certain which administrative policy or policies will
authorize it, how can they be sure they have put it in a place that will
allow it to be authorized ? The writers of administrative policies have the
similar problem of not being sure they have put the administrative policy in
the places it needs to be to authorize the access policies yet to come.
Evaluating administrative requests from the top removes sibling adjacency as
a concern and the feature operates unfettered.

I also said this:

    [ In the current scheme ] "the effect of a nested AdminPolicy depends on
    where evaluation of the administrative request begins. Suppose that the nested
    AdminPolicy evaluates to Deny. If the evaluation of the administrative request
    started inside the AdminPolicySet, then the AdminPolicy has no effect because
    it doesn't add an arc to the reduction graph. If the evaluation of the administrative
    request started outside the AdminPolicySet, then the Deny result from the AdminPolicy
    is combined with the results from its siblings according to the combining algorithm
    of the AdminPolicySet. If that combining algorithm is deny-overrides, then the
    Deny result overrides any Permit results from the siblings. That sort of
    variability will make delegation hard for users to understand."

Evaluating administrative requests from the top means that the result of an
administrative policy is always combined with the results of its siblings
according to the combining algorithm of the policy set in which it is found
- with no exceptions.


Yes, that is true, but I would not expect anyone to use delegated admin policies inside an admin policy set.
(In fact, we could forbid that explicitly.) Also, I am not sure it's a lot easier to grasp the big picture
in case of nested untrusted admin policies even if the evaluation jumps up to the top level for each
untrusted admin policy. It's going to melt most people's brain anyway. ;-)


In the current scheme, the reduction of an untrusted policy considers each of
the sibling administrative policies by evaluating the administrative request
against them. The effect of the reduction graph is to combine the results of
those evaluations in a way that is similar to, though not exactly, the
permit-overrides combining algorithm. This is the only predictable way to
combine the results of administrative policies, whether I like it or not, and
I don't. I particularly want to use deny-overrides. If I put the administrative
policies inside an administrative policy set with the combining algorithm I
want, then that's not reliable, for the reasons above. The practice might as
well be forbidden if it can't be trusted, but either way, policy writers are
condemned to only combine the results of administrative policies according to
something like permit-overrides. Evaluating administrative policies from the
top every time means that policy writers have the flexibility to use whatever
combining algorithm they want, knowing that it will always work as specified.

And I said this:

    [ In the current scheme ] "evaluation of an administrative request always starts
    with the pair-wise consideration of siblings of the policy being reduced. It is
    a process that is different from the normal processing of a combining algorithm
    and, in fact, completely disregards the combining algorithm of the policy set
    that contains the access policy and its sibling administrative policies. Starting
    the evaluation of the administrative request at the top (just like an access
    request) would be simpler to manage and easier for users to get their heads
    around."


When I read this, I am not sure, but do you imply that there is no reduction graph construction at the top
level.


Correct. The administrative request is evaluated according to section 7.17 of the
core, subject to the additional requirement that any access policy or access
policy set is automatically NotApplicable.

> BTW, what does the reduction graph look like in your proposal?

There isn't one.

Regards,
Steven

> Which policies participate in it? How

is it built?

Best regards,
Erik

Regards,
Steven


Best regards,
Erik


On 2012-12-18 07:17, Steven Legg wrote:


Hi Erik,

On 18/12/2012 2:32 AM, Erik Rissanen wrote:

On 2012-12-14 04:28, Steven Legg wrote:

On 13/12/2012 11:36 PM, Erik Rissanen wrote:
> So why do you allow for the hybrid?

To overlay the administrative and access policy set hierarchies. Some
folks have expressed a dislike for a complete separation.


I don't see that you need hybrids even if the admin hierarchy is overlaid. Can you give an example?


Suppose I want to write a bunch of admin policies that all relate to
a resource with a resource-id of "printer", so I factor out the
resource-id test and wrap the admin policies in an admin policy set
like so:

AdminPolicySet {
    PolicySetId: PS1
    Target: resource-id="printer"
    AdminPolicy {
        PolicyId: P1
        ...
    }
    AdminPolicy {
        PolicyId: P2
        ...
    }
}

Along comes the delegate, who creates some access policies that relate
to the resource with a resource-id of "printer". If the delegate factors
out the resource-id test and wraps the access policies in an access
policy set it looks like this:

PolicySet {
    PolicySetId: PS2
    Target: resource-id="printer"
    Policy {
        PolicyId: P3
        ...
    }
    Policy {
        PolicyId: P4
        ...
    }
}

This represents a complete separation of access and administrative policy.

In my proposal I don't allow AdminPolicy in a PolicySet, or Policy in an
AdminPolicySet, not because it is harmful, but because it is pointless.
Recalling that I am proposing evaluating administrative requests from
the top, an AdminPolicy in a PolicySet will never get evaluated because
the PolicySet is not applicable to an administrative request. Likewise,
a Policy in an AdminPolicySet will never get evaluated because the
AdminPolicySet is not applicable to an access request. In order to take
advantage of the common targets for the two policy sets above and merge
them into one I need a policy set that is applicable for both access
requests and administrative requests. That thing is the HybridPolicySet:

HybridPolicySet {
    PolicySetId: PS3
    Target: resource-id="printer"
    AdminPolicy {
        PolicyId: P1
        ...
    }
    AdminPolicy {
        PolicyId: P2
        ...
    }
    Policy {
        PolicyId: P3
        ...
    }
    Policy {
        PolicyId: P4
        ...
    }
}

Regards,
Steven

Follow-Ups:
- Re: Policy Labelling (was Re: Delegation and on-permit-apply-second)
  - From: Erik Rissanen <erik@axiomatics.com>