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


Thanks, Eric. 

Actually I was saying that in the proposed profile it would be an error (and a Deny) if there is any resource attribute associated with the requested resource that was not referenced by any of the policies in the set selected for evaluation of a particular request for that resource. 

The core point is that each resource attribute has been associated with the resource because it is relevant to a Policy (reg, law, etc.) that applies all the time for access that data.  (I capitalize Policy to refer to the underlying law, reg, etc and not a rule that may in effect be a "clause" in that Policy.)  By "all the time", I don't meant that a particular digital rule or the value of a resource attribute it references actually determines the outcome of a particular decision. Many times the Policy permits any of several match conditions to lead to a Permit. That doesn't mean the unmatched conditions are irrelevant, and we don't know in advance whether that condition will determine the outcome of the decision.  

Specifically regarding the idea that an "emergency over-ride" rule makes some or all resource attributes irrelevant, I'd suggest we look carefully. In Mike's medical records examples, I doubt that the over-ride applies to resources that are not "medical records." Unless all that exists in the universe is "medical records" then the resource attribute "medical record" is a necessary part of the access determination. We can't tell from his description, but it may also be the case that the "emergency over-ride" rule only applies if the "medical record" is also marked as "Non-DOD-Affiliated." 

Let me raise a new issue: when we say a Policy applies to a situation, I think we (or at least the policy-makers) mean the full Policy including all exceptions, special cases, etc. So the possibility of an "emergency over-ride" is actually part of the Policy. (And I'd assert that there's no such thing as an "emergency over-ride" that applies to everything.)  This is more than a philosophical issue: it becomes very important when, as is often the case, there are multiple authorities or sources of policies, even within a single organization and certainly in a multi-organizational environment. Typically, the resource owner is responsible for making access consistent with ALL these policies. And to limit the size of this comment, I'll just say that the profile I've suggested might help achieve this compliance by trapping several possible sources of error in coordinating policies and in data-marking operations. 

Regards,

Martin

 









On Thu, Jan 7, 2016 at 3:53 AM, Erik Rissanen <erik@axiomatics.com> wrote:
Martin,

Ok, then I have misunderstood you a bit. I thought that you meant that an attribute was referenced at runtime evaluation, not just that the policies reference it somewhere. I don't think that changes the discussion much though. The same kind of arguments can be made that an attribute might be irrelevant and legitimately ignored by the policies as a whole because the attribute is relevant only in some other context.

As for you looking for "any mechanism, performed by the PDP or elsewhere, that will assure that all resource attributes are referenced by some rule in the set of policies applied to a decision", then that is something which is not present in the XACML standard.

Best regards,
Erik



On 2016-01-05 20:19, Martin Smith wrote:
Eric--

Let's drill down on what is meant by "used."  Let's say that a regulation says that if ANY of three conditions (rules A, B or C) is met, then the resource may be accessed.  Let's say that rule B is not met and (by itself) would result in a DENY, but rule A is met and thus the overall outcome is PERMIT.  Is rule B "not used"?  

I tried to avoid this ambiguity by proposing that the set of rules collected to process a request must contain at least one rule that refers to each of the access-related attributes associated with the protected resource. Just because the set of "active" rules includes one or more rules that do not affect the decision regarding the current request by the current user in the current environment. doesn't mean those rules are irrelevant. At query time, relevancy is determined by the resource attributes; which resource attributes are required to be associated with which resources is determined at "design time", when the policies are developed by governance authorities.

Regarding "what the PDP does not know": an interesting viewpoint. My understanding is that what the PDP knows is (a) a set of policies loaded from the PAP; (b) the Request Context provided by the Context Handler; and (c) additional subject, resource or environmental attributes the PDP may request via the Context Handler. 

My initial thought as to how the PDP might implement the goal of accounting for all resource attributes was for it to request "All" resource attributes. (This is not supported in the current spec as I read it.) My understanding (but I certainly could be wrong) is that the PDP will identify all Policies with a Rule that references any attribute of the requested resource. In addition, my thought would be that the PDP should check that all the resource's attributes are referenced by some rule to be applied to the current request, and if not, then issue a Deny decision, perhaps with explanation. I do not think this checking function can be performed by anything is the current spec. Both the gathering of all resource attributes and the checking and Deny decision would be a selectable option by the implementing organization. 

All this said, I repeat that what I'm looking for is any mechanism, performed by the PDP or elsewhere, that will assure that all resource attributes are referenced by some rule in the set of policies applied to a decision. 

I agree with your statement (as slightly amended): "The current XACML spec simply assumes that you are operating with the correct policies. What you are looking for is some extra information to detect some cases where a mistake has been made in the deployment and the policies [or the applied resource attributes] are not correct." 

Regards,

Martin



      





  

On Tue, Jan 5, 2016 at 3:21 AM, Erik Rissanen <erik@axiomatics.com> wrote:
Martin,

Regarding point 3, what I mean is that the PDP does not know that the DoD attribute is more important than the override. An unrecognized attribute may or may supersede the decisions of a policy which was not authored with the attribute in mind.

Let's say that there are two attribute which are not used by the PDP for making a decision: "DoD" and "Family relation". For the sake of example, let us say that regulations state that in case of emergency a doctor may not see DoD records, but may access data about family members. If emergency override happens, and neither attribute is used in the making of a decision, then the PDP really cannot tell whether this is because the attribute is not relevant in this situation, or that the policies are wrong. In this case the policies would be wrong about the DoD attribute, but it would be correct to not use the Family relation attribute.

The current XACML spec simply assumes that you are operating with the correct policies. What you are looking for is some extra information to detect some cases where a mistake has been made in the deployment and the policies are not correct. You do need extra information because the fact that an attribute is not used is not an error in general, though it might be an error in some cases.

Best regards,
Erik



On 2016-01-04 20:26, Martin Smith wrote:
Eric-thanks for the comments. I'll respond in reverse order .  .

1.  "Maybe there is a need in more open environments and cross-organizational uses, where such life cycle management can get more error prone?"  -- Yes, that is the context that stimulated the proposal: any information sharing environment where that are multiple governance and/or access-related operational processes. This would certainly include federations (industry COIs but also the ID Ecosystem that NIST/NSTIC is supporting) but might also be relevant to large corporation, especially those with operations in different legal jurisdictions (like the US and EU.) 

2.   "If you do a metadata spec . . ."  Interesting idea, and I am certainly not committed to the specific mechanisms I mentioned earlier, which in any case would seem to require Core Spec changes to implement. What would it take to implement your idea? 

3.  "Emergency override is a good example. "  I don't see how this makes the point you suggest it does. In Mike's example, a doctor's assertion of  "emergency over-ride" presumably applies only to the resources marked as "health records", and not, for example, resources marked as "doctor salaries." So you still have to take account of the resource metadata.  And what if the resource metadata (found in Mike's second example in the resource content) says the patient is affiliated with "DoD"?  Does the doctor's "emergency over-ride" apply to that record?  Better check all the constraints..  Also, it doesn't seem quite accurate to say that the access policy that applies to resources marked "HIV" is "ignored": in fact, the policy seems to be "access to records marked 'HIV' is limited to [some group, but not all doctors] unless the request is by a doctor who also asserts the existence of a life-threatening emergency."  So, we are talking about how such a policy can be implemented in XACML, which as far as I can tell requires two rules applied according to a combining algorithm. 

Thanks again and best regards,

Martin


On Mon, Jan 4, 2016 at 3:29 AM, Erik Rissanen <erik@axiomatics.com> wrote:
Martin,

I agree with John and he has a great example with the emergency override. It's a good example of what I was thinking of in my earlier reply in the other thread. The policies are authoritative (or you have bigger problems to worry about) and know which attributes are needed and not all available attributes may be needed in each situation.

Emergency override is a good example. If an emergency override has been done, then many attributes no longer matter because very wide access is now permitted for emergency purposes. There is nothing wrong with the combining algorithms. It's just that this is the explicitly desired behavior of the system in that case, and that's what the policies do in this situation because of that's what we want the policies to do. Since in this situation we explicitly _want_ these attributes to be ignored, there is no way you can create a mechanism which can detect that "something is wrong" because in fact nothing is wrong.

Going back to your original problem statement, if a new attribute is added to a resource, you want to ensure that it is used to protect the resource, then you have to handle this be making sure that the policies of your organization/system are also updated. The PDP would not be able to tell the difference between an attribute which has been "forgotten about" when the policies were written and an attribute which is not needed because it is not relevant for the situation.

The way to approach this problem is to ensure that you maintain the lifecycle of our policies and applications so that you ensure that the PEP and policies are in sync.

If you are looking to create a standardized mechanism to try to detect mistakes like this, I think you have to create an metadata profile, rather than trying to piggyback the PDP evaluation. You cannot rely on the PDP evaluation path to detect this since the PDP has only the policies to rely on and it cannot tell apart a missed attribute from a non-relevant attribute.

If you do a metadata spec, you could instead let a PEP publish a statement such as "I expect that the policies take into account the full relevance of the following attributes: foo, bar, etc". The policies could then be marked with a corresponding statement "These policies have been authored with the attributes foo, bar, etc, in mind". These two docs could then be compared and if the PEP publishes an attribute which has not been considered while the policies were authored, then you know that something is wrong. And conversely, if the metadata documents match up, but not all attributes are used, then you know that the situation means that the "missed" attributes are simply not relevant for security requirements of that situation.

I would say that's the direction to go, but I have my doubts about how much a problem this is in practice. You need to take the correctness of your application and policies into account anyway, so you would have test cases and you would manage the life cycle and versions of your components anyway. Maybe there is a need in more open environments and cross-organizational uses, where such life cycle management can get more error prone?

Best regards,
Erik



On 2016-01-04 05:26, Martin Smith wrote:
Mike-- Thanks for the thoughtful response and Happy New Year!  You raise some good issues. 

Here are some initial reactions: 

1.  The idea that resource "attributes" may be contained in resource content is built into the XACML spec. This is illustrated in your example in which part of the patient record (i.e. that the patient is DOD-affiliated) is serving both as "payload" data and access-control metadata. The goal of accounting for all access-control resource attributes requires figuring out where they are, and I haven't thought specifically about how to identify those parts of content that should be considered as metadata.

2.  Your example of "emergency access" (and the DOD one, too) raises another issue I hadn't focused on:  the role of the combining algorithm. Suppose one can collect all the policies that refer to all the access-related metadata associated with a resource and determines that each resource attribute is used by at least one of those policies. Even so, if the combining algorithm stops processing once it finds one rule that is satisfied, then the goal of giving each resource attribute a chance to "protect" the resource is not achieved. So, it looks like the profile I'm hoping to develop must set some conditions for the combining algorithm.

3. Regarding: " . . . different policies based upon attributes of the requester, environmental etc. . . . "  Lets look at this from a "data-centric" point of view. The set of constraints (policies derived from laws, regs, contracts, etc.) that applies to a particular protected resource does not vary (unless laws, etc. change.) To be compliant, every access must meet every constraint that applies to that resource. Each resource attribute is there because it identifies an access-relevant characteristic that is linked to a policy that applies to that resource. If that policy is not included in the policy set that is processed for a request to access the resource, then something is wrong. (This does not mean that a particular rule cannot be pre-empted by another rule that expresses a permitted exception, like an emergency provision, and which is effectively given precedence via the combining algorithm.) 

4.  I am a little puzzled by your distinction between the "sensitivity" of a resource (which seems to be related to privacy policies) and other access-relevant characteristics.  It seems to me that all the access-relevant characteristics of a resource ought to be expressed in terms of resource attributes. Might be worth some discussion. 

Again, thanks for your thoughts and questions, and particularly for the real-world implementation examples. 

Regards,

Martin
 







  








On Sat, Jan 2, 2016 at 10:59 AM, Davis, John M. <Mike.Davis@va.gov> wrote:

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
Sent: Tuesday, December 29, 2015 7:23 AM
To: Hal Lockhart; William Parducci; XACML TC
Subject: [EXTERNAL] [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. 

 

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 389-3224 mobile



 

--

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102

703 389-3224 mobile




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




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




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