RE: [xacml-dev] access-permitted questions

["GRIFFIN, GLENN (GLENN)" <glenngriffin@research.att.com>]

Hal,

The kind of case that I am thinking of is the difference between, say, a bound of 5 and one of 6.  This could lead to:

	Run a test on compliant PDP A with bound = 6  -> Permit/Deny
	Run same test on compliant PDP B with bound = 5  -> Indeterminate with limit exceeded.

This seems to me to be a quite different result from 2 PDPs that are both compliant.  Given that this feature is not in high demand and you have confirmed that there is no standard for that bound I am not concerned about it . Users of this feature who switch PDPs will just have to deal with that difference.   I'm just noting that it is possible and thus something that the TC may wish to address at some point.

Glenn

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@oracle.com] 
Sent: Tuesday, December 10, 2013 1:25 PM
To: GRIFFIN, GLENN (GLENN); Erik Rissanen; xacml-dev@lists.oasis-open.org
Subject: RE: [xacml-dev] access-permitted questions

The TC has tried hard to ensure that the same policies with the same inputs will produce the same Effect (Permit or Deny) using any compliant PDP. However the same is not true for other results. For example, it is possible to get different Obligations and Advice.

The case you are talking about is essentially about error handling. The two possible results are that the PDP will loop endlessly (which raises operational issues) or it will report an Indeterminate result with limit exceeded.

If a set of policies have been realistically tested and a subsequently decision request requires a much greater depth of recursion, then it seems reasonable to me to treat it as an error and address it administratively.

The fact of the matter is we do not know of any terminating algorithm for determining in the most general case whether the policy evaluation (reduction or access-permitted) will terminate. In fact we don't know of any algorithm other than evaluation of the policies to determine of the evaluation will terminate. So rather than forgo this useful functionality we have chosen a pragmatic, if inelegant approach.

Hal

> -----Original Message-----
> From: GRIFFIN, GLENN (GLENN) [mailto:glenngriffin@research.att.com]
> Sent: Tuesday, December 10, 2013 1:08 PM
> To: Hal Lockhart; Erik Rissanen; xacml-dev@lists.oasis-open.org
> Subject: RE: [xacml-dev] access-permitted questions
> 
> Hal,
> 
> Thank you for the very detailed answer.
> 
> If I am reading this correctly it does not rule out the possibility 
> that Policy/Request combinations that work on one implementation might 
> not work on a different one because of the internal bound being 
> different, but we do not know enough at this point about actual usage 
> of the feature to be able to define a standard minimum value.
> 
> From what I've read it seems that this is not a highly-used feature, 
> so that's ok.
> 
> Glenn
> 
> -----Original Message-----
> From: Hal Lockhart [mailto:hal.lockhart@oracle.com]
> Sent: Tuesday, December 10, 2013 12:33 PM
> To: GRIFFIN, GLENN (GLENN); Erik Rissanen; xacml-dev@lists.oasis- 
> open.org
> Subject: RE: [xacml-dev] access-permitted questions
> 
> 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