[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?
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:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]