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.
Suggestions?
Martin