[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [EXTERNAL] [xacml] Default behavior for unrecognized resource attributes?
Martin, Please elaborate. As I understand it, access control attributes of a resource are there to be used by a policy that determines what decision and obligations need to be made based upon the presented claims of a requester and other contextual attributes. In VA, we control sensitive patient information but it is also common to have different policies based upon attributes of the requester, environmental etc. For example, consider the following: Case 1: VA receives a routine request from entity A for access to patient X records. The policy requires that A present attributes (clearances, tokens etc ) for portions of a record marked with sensitivity “HIV”. If A does not present the HIV clearance, then the decision may be to deny or an obligation is thrown to redact or mask the HIV information before responding. However, if A asserts the purpose of use of “Emergency Access”( = imminent death or injury), then the information is released solely based on the purpose of use alone. Case 2: VA receives a request from DoD for access to patient X. The policy requires allows release to any member of DoD based purely on affiliation (e.g. DoD). Here the decision is made and the record released without any reference whatsoever to the resource attributes. Summary Case 1 Shows that the context of the case can determine whether resource attributes are even considered at all as the request itself may drive different policies for a given resource (Normal vs Emergency access). Case 2 shows that there exist real-world examples where the sensitivity attributes of a resource are irrelevant to the decision. In fact, it is the policy that determines which resource attributes are relevant based upon evaluation of the request, context etc (e.g. purpose of use, organization, Role, location) applied before any consideration of resource sensitivity. Am I mis-understanding? It appears to me that your point 3 is incorrect. Do you really mean that all attributes of a resource referenced in a given policy must be accounted for in the decision? The point is that the sensitivity of a security attribute is relative to the context and in some cases (e.g. HIV) need not be evaluated at all (POU=emergency access). Finally, it would seem that in some cases considerations other than resource sensitivity attributes might be the source of policy for an access control decision (e.g. compartment to which the user belongs=access is granted if requester is a member of the pharmacy group) Regards, Mike Davis VHA Security Architect 760-632-0294 From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Martin Smith 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 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. Hal -- 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]