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: [xacml] Default behavior for unrecognized resource attributes?

Hal, all-

I am pursuing Hal's suggestion below to explore the possibility of developing a profile that would assure that all access-related attributes of a resource are used by the set of policies applied to a request. 

To summarize the need: 1. in sensitive environments, all access-control policies applicable to a request have to be enforced; 2. access-control attributes of a resource are there for a reason: to advertise some characteristic of the resource that requires limiting access to it. 3. Therefore, If the set of policies applied to adjudicate and access request does not reference each resource attribute, something is wrong. 4. In a sensitive environment, the appropriate response is caution: to Deny access to the resource pending resolution of the disconnect between the collection of policies and the resource attributes associated with the resource. I ran this summary by a current USG IDAM policy expert who agreed it would be a useful control, but of course this is not definitive validation. 

As Hal says, in other environments it may be appropriate to ignore resource attributes that are not used (referenced by any applied policy) for some requests. 

Moving on to how the goal of the profile can be implemented with the tools available in the existing Core spec, I have dug in a bit but I'm sure I don't understand all the capabilities anywhere nearly as well as others in the TC and those who have implemented it, so I am hereby asking for suggestions/corrections. 

1 .My initial thought is that whatever else is needed, one thing is the ability for the PDP to ask the context handler to retrieve all (access-related) attributes of the requested resource. I don't see a way to retrieve "All" of a resource's attributes. 

2. I was thinking the next step would occur after all (other) policies applicable (based on their Target expressions) to the current request have been gathered. (per description in 2.9 Policy Distribution and 2.10 Policy Indexing of the spec.)  At that point, one would like to compare the list of resource attributes to the list of attributes mentioned in this set of policies. 

3. Finally, if there were any un-referenced resource attributes, a Deny would be returned to the PEP, optionally with a list of the un-referenced resource attributes. 

I see nothing in the spec that looks like it would perform the work in 2. and 3. but as I said I am not at all expert on its capabilities. 

Of course perhaps there might be a totally different way to accomplish the goal that I am not seeing. 



On Thu, Oct 29, 2015 at 2:19 PM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

I think the summary of my reaction to your comments is that many of these things will be true in some environments, but none of them will be true everywhere. XACML aspires to be suitable for all access control environments, or at least to be as widely useful as possible. Therefore, it does not seem to me to be a good idea to require behavior in the core standard which is not useful in many environments.


Perhaps there is some way your requirements could be met by a profile which would only apply where it is needed.


More comments are inline.




Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102

Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile

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