RE: [xacml-dev] access-permitted questions

[Hal Lockhart <hal.lockhart@oracle.com>]

Responses inline.

GLENN GRIFFIN wrote: 


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

This is not correct. The Schema to support the Administration Profile has always been a part of core. The processing rules for the Administrative profile appear there, since we wanted to make the profile optional. (The processing rules for MaxDelegationDepth are in 4.9, 4.10 & 4.11 of the admin profile.) Note that as of now, a number of organizations have implemented the core, but not the administrative profile, thus validating our judgment.

I originally proposed access-permitted based on a feature of the then proprietary BEA AES (now Oracle OES) product. The motivating usecase is the common situation where you want to say Jack can only do what Mary can do (and possibly less). This corresponds to the common situation where resources are being managed on behalf of their owner. This is common in Cloud-like environments and even can hold in a corporate situation. See OAuth and UMA for example usecases. Of course it is possible to create an explicit policy which corresponds to the policy for Mary, but this makes the intent less clear and is more work and more error prone to keep the policies aligned as Mary's policies change.

For example, Mary wants to let Jack read her files but not write them. But the overall system needs to insure that the files in question are only ones Mary is allowed to read in the first place. Rules about read-only can be combined with access-permitted(Mary) to get the desired result. This function can be used with or without the Admin profile.

The functionality of the Admin Profile and the critical reduction algorithm was originally developed for the Swedish DoD by Erik and his collaborators. The Admin Profile differs in some details, but conceptually works in the same way as the orginal. There are two types of policies Access and Admin. Admin policies determine if untrusted Access Policies are valid for a specific decision.

As you note, the access-permitted was originally in the Admin profile, since it represents a form of delegation. Later we decided to move it to core, since it does not use reduction, although a portion of the processing is similar to some of the steps in reduction.

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

For reduction we decided to let the policy author control the depth of recursion on a per-Policy Set basis. For access-permitted we decided on a PDP-wide parameter.

Over the years we have developed a number of PDP-wide parameters, such as PDP bias, default top level policy combining algorithm and the conformance points supported. The intention was to put all of these in a Metadata Profile, modeled on the SAML metadata profile. The idea would be that PDPs could advertized their metadata in one of several ways. The metadata profile has never been finished, but there is a draft in the archive.

The reason we have provided no mechanism to set the invocation bound on access-permitted is that the TC has in general chosen not to specify how either policy authoring and management or PDP administration is done, leaving it up to individual implementations. The reasoning has always been that these areas are not well understood and there is little value to users to provide interoperability in these areas. Further it offers vendors an opportunity for differentiation.

IMO, both MAXDelegationDepth and the invocation limit are likely in practice to be set based on the result of testing of specific collections of policies. Typically you might determine the depth actually observed using test inputs and set the value a little larger than that. Perhaps eventually less crude approaches will be discovered, but it is not a good idea to standardize things that are poorly understood. Note my proposed approach assumes instrumentation of the PDP which is also unspecified by XACML.


>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 ☺.  It would also make this feature useless.  So let’s 
>look at a (slightly) more realistic example.

One thing I have learned about standards is that it is never necessary to worry that implementers will conform to the letter of a standard by doing something useless. The community would reject such an implementation and in practice implementers tend to either leave it out or do it right. Actually a value of 1 would allow a single invocation of access-permitted, which WOULD be useful. A value of 0 would selectively disable the use of this function, but would IMO be a slightly strange way of doing it.

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

Most of the usecases I can think of relate to Subject attributes. In addition to John can do what Mary can do, suppose John needs to join a project temporarily for review or to provide some special skill on a short term basis. We could say Jack can do only things members of the project can do. The function was made more general because we have often discovered that users find ways to use features in ways we never imagined.

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

If you are not concerned about denial of service attacks or frequent policy design errors, you can sent both limits to very high values. The parameters are intended to give managers of PDPs to address these concerns, since there is no real way the policy evaluation algorithms can prevent endless evaluation. The big reason that MaxDelegationDepth is specified in the Policy Set is that for example, when the just-in-time policy feature in the SAML profile is used, the PDP may have to evaluate a policy we know nothing about except that it has a valid signature.

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

There are a number of implementations of XACML 3.0, but we left access-permitted as optional, so I do not know. Axiomatics and ViewDs have implemented practically everything in every spec, so I suspect they have implement it. I am not sure if Oracle has carried over the implementation. I will check.

Hal

>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