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)


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

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





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