RE: [xacml-dev] access-permitted questions

Hi Erik,

Thanks for the reply.

I understand from the archive emails that MaxDelegationDepth and access-permitted were both moved from the Delegation Profile into the Core at the same time. Since access-permitted is the Core version of the “reduction” tree operation from the Delegation Profile and MaxDelegationDepth is the limit for the recursion in that tree as taken from that Profile, it seemed natural that they would still be related. As a matter of fact it seems odd that they are not since either one without the other is incomplete and they were moved to the Core together as a pair.

If the bound in A.3.16 is not MaxDelegationDepth, then it seems insufficiently specified since it affects the ability of a user to use this feature. If it is implementation-specific, we could, for example, choose to set it to 1. That would certainly stop an infinite loop J. It would also make this feature useless. So let’s look at a (slightly) more realistic example.

The only example we have been able to find for using this feature comes from the Delegation profile where A is Permitted if B is permitted if C is permitted.... (PLEASE – Any other examples? Anyone?)

Let us say that this is intended to match an organizational structure where A is a VP, B is a Division Manager, and so on.

If the choice for the bound is entirely up to the implementation (and therefore could be hardcoded into it), we could choose the bound = 2.

That would prevent users from creating Profiles and Requests that allow access for Department Heads, Supervisors and System Administrators.

Without either some statement in the spec or some way to set this limit in the Profiles, the only way that users know whether their Profiles and Requests will work is by the Implementation-specific documentation or by experiment. Since XACML is a standard, it should be possible to switch between implementations, but that may not be possible in this case. This bound needs to be further defined (e.g. “greater than 10”) for users to be able to rely on this feature to do what they need.

So we have a limit in the Core which is not used by the Core (why wasn’t MaxDelegationDepth left in the Delegation Profile if that is the only thing that needs it?) and a place where a limit is referenced but not specified.

By the way, have you folks implemented this feature? If so, how did you choose the value for the bound?

Do you have concrete examples of access-permitted usage?

Thanks,

Glenn

From: Erik Rissanen [mailto:erik@axiomatics.com]
Sent: Tuesday, December 10, 2013 3:33 AM
To: xacml-dev@lists.oasis-open.org
Subject: Re: [xacml-dev] access-permitted questions

Hi Glenn,

MaxDelegationDepth is not related to access-permitted. The specification for access-permitted is in section A.3.16 only. MaxDelegationDepth has to do with the delegation profile only.

The bound which is mentioned in A.3.16 is meant to be an implementation specified parameter to make sure that the PDP does not go into an infinite loop.

Best regards,
Erik

On 2013-12-09 17:28, GRIFFIN, GLENN (GLENN) wrote:

Folks,

We are trying to understand the access-permitted function and have a few questions.

Does anyone have concrete examples (Policy, Request, Response files) using this function?

Has anyone implemented this function?

The paragraph on detecting loops is confusing with respect to the MaxDelegationDepth attribute on the Policy. Historically it seems they both came from the Delegation Profile, but in the current Core spec there is no connection between them. Is there supposed to be? Is MaxDelegationDepth the limit for the number of loops? The function definition just says “exceeds the bounds” without identifying what the bounds are or where they come from. Is this identified anywhere?

Thanks,
Glenn Griffin
glenngriffin@research.att.com

xacml-dev message