[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?
+1 too, except you should not use set equals, but allOfAny since the set of understood attributes may be a super set of the set of attributes which must be understood. Best regards, Erik On 2016-02-04 16:19, Hal Lockhart wrote: > +1 > >> -----Original Message----- >> From: Steven Legg [mailto:steven.legg@viewds.com] >> Sent: Sunday, January 31, 2016 11:48 PM >> To: rich levinson >> Cc: Martin Smith; XACML TC >> Subject: Re: [xacml] Re: [EXTERNAL] [xacml] Default behavior for >> unrecognized resource attributes? >> >> >> Hi Rich, >> >> On 21/01/2016 8:41 PM, rich levinson wrote: >>> Here's my 2 cents as far as I understand the issue: >> I'll match your monetary investment. >> >>> I think one way it could be supported is to have something like a >>> MustUnderstand optional piece of Attribute metadata, that could work >>> something like this: >>> >>> if an attribute is present w the MustUnderstand xml-attr == Deny, >>> then if the policy does not understand the attribute, and the >> decision >>> otherwise is Permit, then result should be Deny, >>> and if the decision ow would be Deny, then Deny >>> >>> similarly >>> >>> if an attribute is present w the MustUnderstand xml-attr == >> Permit, >>> then if the policy does not understand the attribute, and the >> decision >>> otherwise is Permit, then result should also be Permit, >>> if the decision ow would be Deny, then Deny >>> (this latter block looks like a no-op, so maybe this case is N/A) >>> >>> However, the first block seems somewhat logical, and possibly there >> is >>> a way to list all the attributes used in the policy and if the one w >>> the MustUnderstand is not on the list then the Rule to Deny would be >>> applied. >> Rather than a MustUnderstand XML attribute I suggest defining an XACML >> resource attribute that contains a list of the identifiers of the >> attributes that must be understood. This has the advantage that it >> requires no change to the XACML core specification. The policies could >> be structured so as to check that the provided list conforms with the >> expectations of the policy. For example, by wrapping everything in a >> deny-overrides policy set containing a policy with a deny rule that has >> a condition that checks whether the MustUnderstand XACML attribute bag >> is not equal to a literal bag (i.e., not(string-set- >> equals(resource.MustUnderstand, string-bag(foobar1, foobar2, ...)))). >> The result is deny if the expectations of the authority responsible for >> the resource (rather than specifically the PEP or PIP since resource >> attributes can come from either) don't match the expectations of the >> policy writer. This also requires no new features in the core >> specification. >> >> This solution is entirely opt-in. Deployments that don't want to use it >> can safely ignore the MustUnderstand attribute. Since no new core >> functionality is required, just about any general-purpose XACML product >> can claim support for it already for deployments that do want to use >> it. >> >> For completeness, an XACML attribute is identified by category ID, >> attribute ID and data type ID. The MustUnderstand attribute being a >> resource attribute takes care of the category ID. The values of the >> attribute should therefore be strings containing the concatenation of >> the attribute ID and data type ID. XACML IDs are compared code-point by >> code-point, which is exactly how string-set-equals works. >> >> In theory a PAP could be written to automatically scan a collection of >> policies for referenced resource attributes and wrap them with the >> appropriate test of the MustUnderstand attribute. Worst case, the >> policy writer does it manually. >> >> Steven >> >>> Above is not a recommendation, but a thought on how it might be >>> approached if someone wanted to build a profile that used the >> capability. >>> However, I would defer to Erik and Stephen, as to whether it is >>> readily implementable or not. >>> >>> Thanks, >>> Rich >>> >>> On 1/21/2016 12:19 AM, Martin Smith wrote: >>>> Eric, all-- >>>> >>>> Your description of the scenario I envision is almost what I meant, >> but I don't understand this: >>>> "Later on, the PEP is changed so that it sends a new attribute >> called >>>> "privacy_controlled"". What I meant is that the relying party adds >> a >>>> tag to the resource. As far as I know the PEP has no way of knowing >>>> this new tag has been added, unless by saying "PEP" you include the >>>> RP resource itself somehow. And in any case, my understanding is >> that >>>> the PEP (or "context handler"?) only collects tags mentioned in the >>>> active policy set, or those asked for by the PDP. I am probably >>>> confused, but I don't see any XACML function through which any IAM >>>> component collects ALL access-related resource tags (specifically to >>>> include those NOT referred to by any rule in the active policy set.) >>>> >>>> Moving on to the question of utility: Eric is correct that this >>>> addresses only one class of error, but I'd assert that it's a very >> likely source of error. The organizational process of creating and >> deploying policies is likely centralized, or at least coordinated >> within a data governance "committee." The data-tagging process is >> likely to be run by more operational units, and there may be many >> separately managed protected resources (that should be ) subject to the >> same enterprise set of laws and regs. These data resources are likely >> to be more dynamic than the policies as new sub-sites are added, for >> example, to a portal. This the coordination between policies and tags >> is likely to be more error-prone. One type of error--where the resource >> manager fails to add an appropriate marking-- should be caught since >> the related policy will not be satisfied. But if a resource owner adds >> a tag, either one in a new data series (perhaps from another >> organization), or an obsolete one because his marking guidance is out >> of date, or because the marking application/tool hasn't been updated. >> One would like to catch these errors. >>>> Finally, remember that per Hal's advice the idea is to make this a >> profile, so that only implementers who are very concerned about these >> errors (and would rather block them than risk an access error) would >> use it. And eve that can be made less "disruptive" if the profile would >> include a selectable option to provide "Advice" (of an unused resource >> attribute) rather than a Deny. >>>> Regards, >>>> >>>> Martin >>>> >>>> >>>> >>>> >>>> On Fri, Jan 15, 2016 at 4:17 AM, Erik Rissanen <erik@axiomatics.com >> <mailto:erik@axiomatics.com>> wrote: >>>> Hi Hal, >>>> >>>> Imagine that you have a deployment of a PEP and PDP with >> policies in production. The PEP sends a bunch of attributes about >> documents. >>>> Later on, the PEP is changed so that it sends a new attribute >> called "privacy_controlled", which is needed for a new privacy law. >> However, nobody updates the policy. In this case Martin wants to detect >> that the policy is wrong because the new attribute is not used. He >> argues that since the PEP sends this attribute, the PEP expects that >> this attribute should be taken into account, thus it should be >> mentioned in the policy. >>>> That the policy does not conform to the new privacy law is a >> type 2 error. It is detected in this case by the missing attribute >> reference in the policy. >>>> The points I have been raising is that this is a very specific >> case, and I don't think it is correct to assume in general that because >> the PEP sends an attribute, that attribute is critical and must be part >> of the policy. Enforcing this kind of behavior in a standard would mean >> that the PDP is going to be unusable in the situations where these >> assumptions do not hold. >>>> If you want to specify a mechanism of detecting this specific >> kind of error, it should be done by means of metadata. The PDP could >> publish a statement saying "I am operating with a policy which has been >> authored with the attributes foo, bar, ... in mind." Whether that means >> that all attributes are used or not is something which the policy >> author decides. In any case, the PEP can check whether the attributes >> it thinks are relevant have been taken into account when the policies >> were authored. >>>> My second, separate point is that I don't think this kind of >> feature is very useful. There is much more to correctness of policies >> and there exists well known general tools and processes which can be >> used to ensure that the right set of policies are used. Since you need >> to do that anyway for so many other reasons, this special corner case >> that a missing attribute may in some cases indicate an error is not >> worth implementing in my opinion. >>>> Regarding you question about the Auditor tool, yes it could be >> used to test that an attribute impacts the decision of the PDP as >> expected. But as you say, the requirements (test cases) must be >> correct. If nobody updates the test cases, then obviously the tool will >> give the wrong result, in the sense of real world requirements. >>>> Best regards, >>>> Erik >>>> >>>> >>>> >>>> On 2016-01-14 20:33, Hal Lockhart wrote: >>>>> I don’t really understand your point. The Policy Auditor is >> always going to compare the invariants you specify with the policy. If >> you specify the wrong invariants, you will not get the right answer. >>>>> If the “true policy” is in your brain, we can never know if you >> have expressed it correctly as xacml policy, tool invariants or natural >> language prose. If on the other hand the “true policy” is a law or >> regulation, then you need a translator from natural language, which is >> well known to be an unsolved problem. >>>>> My point is, strictly speaking we can never solve your type 2 >> problem. Until the “true policy” is rendered into unambiguous form we >> cannot do any automated analysis on it, period. >>>>> Going back to the idea of using the Policy Auditor to answer >> Martin’s question, are you saying that there is some limitation in the >> tool’s ability to do this or that we can never be sure if the specified >> invariants correspond to the “true policy”? >>>>> In other words, if we were willing to stipulate that the inputs >> to the Policy Auditor do correspond to the “true policy” could we use >> the tool for this type of analysis? >>>>> Hal >>>>> >>>>> P.S. I do not claim yet to understand what condition Martin >> wants to test for, but you seem to. >>>>> *From:*Erik Rissanen [mailto:erik@axiomatics.com] >>>>> *Sent:* Friday, January 08, 2016 3:15 AM >>>>> *To:* Hal Lockhart; Martin Smith >>>>> *Cc:* XACML TC >>>>> *Subject:* Re: [xacml] Re: [EXTERNAL] [xacml] Default behavior >> for unrecognized resource attributes? >>>>> Hi Hal, >>>>> >>>>> I agree with you on all points. >>>>> >>>>> As for your question about Axiomatics products, you must be >> thinking of the Axiomatics Policy Auditor. I think that product is >> about a slightly different issue than what Martin is concerned about. >>>>> With the Policy Auditor you can test that policies comply with >> certain invariants. You could for instance create a test case which >> says that a resource is export regulated and that the location of the >> subject is in North Korea. All other attributes would be left as open. >> What the product can then calculate is whether given these two >> attributes, regardless of any other attribute values, it can check that >> the decision would always be Deny. If not, it will give a specific >> example of a request where the decision is not deny. >>>>> Another example would be that you create a test case saying >> that emergency override is in effect, then the decision should always >> be Permit. Again, if this is not true, the logic analyzer will find >> examples of violations, so you can fix your policies. >>>>> The point is to do "open ended" testing in order to validate >> invariants by means of a logical proof. This is different than doing a >> large set of regular XACML request test vectors, because with such >> enumerations you cannot know for sure that there won't be another test >> case which would violate your requirements. The space of all possible >> access requests is infinite, so it cannot be enumerated fully. >>>>> This kind of testing is a bit different from what I think >> Martin is looking for. You could use the Axiomatics product to test >> your policies, but it does not help you with the coordination that the >> policy package which the PDP is using corresponds to the set of >> requirements that the PEP is expecting. >>>>> To state that again using different words, there are two kinds >> of errors which can happen: 1) Given your requirements the policy might >> not do what it should do (here the Axiomatics tool helps you), or 2) >> The policy corresponds to a set of requirements, but these requirements >> are the wrong ones. >>>>> A "type 2" error could happen in a federated environment for >> instance when a new requirement is introduced, and the PEP and the PDP >> are not within the same life cycle coordination. It could be that a PEP >> is deployed with a new set of requirements in mind without the PDP >> having been updated. >>>>> To guard against type 2 errors, you could use project >> management processes. To detect it at runtime, I think a metadata >> exchange would be needed because there is nothing in any set of >> policies which allows the PDP to a priori assume that the policies are >> wrong. >>>>> Best regards, >>>>> Erik >>>>> >>>>> On 2016-01-07 17:58, Hal Lockhart wrote: >>>>> >>>>> I am just catching up with this thread. >>>>> >>>>> I think there are at least two separable issues which have >> become a bit entangled. >>>>> 1. what is needed and how best to accomplish it. >>>>> >>>>> 2. whether it is a reasonable requirement, or alternatively >> how common is this environment. >>>>> In the earlier discussion, I largely ignored #2. The idea >> of a Profile is that it is a set of functionality which is seen as >> useful by all or some members. It is optional for anyone to support a >> Profile even if they support the core. Before a Profile (or any spec) >> becomes an OASIS Standard, we need 3 Statements of Use, which is >> intended to demonstrate there is at least some level of interest in >> actually using it. >>>>> IMO, one can object to a Profile that forces mandatory >> behavior which is seen as harmful or interferes with other mechanisms >> you depend on. Or you can object on technical grounds that the proposed >> scheme will not function as described. Alternatively, you can object >> because you want to use the Profile, but the proposal does not contain >> features you need. However, it is rarely necessary to object on the >> grounds that nobody needs it. >>>>> Therefore I will focus on #1. >>>>> >>>>> Let’s start with the basics. In XACML Attributes are all we >> know about anything. Everything that a policy can use as data is an >> Attribute of something. XACML merely assumes that the Attributes we >> need are somehow available in the environment. In practice they usually >> come from existing, non-xacml sources, which make them available by >> preexisting means which we have no way to influence. For example, a >> file as a resource would have a name, modification data, size, owner >> among other data. The means of obtaining attributes of all kinds for a >> given sort of Resource (or Subject) will probably be the same. >>>>> My conclusion from this is that to do what Martin wants, >> whether at policy deployment time or at decision time will require some >> kind declarative mechanisms that says “these are the attributes/values” >> which are critical to access control and the others are not. I see no >> way for the PDP or context handler or PAP to make this distinction, nor >> any way to insure that only one or the other type is present when >> attribute values are obtained from their sources. >>>>> XACML attributes can be single valued or multi-value. The >> way information is encoded in attributes is not specified by xacml for >> the simple reason that they usually exist in advance of their use in >> policies and typically it is not possible to change their structure. >> For example, suppose there are properties Red, Green, Blue associated >> with resources. This could be represented in at least 3 ways: 1) Single >> value enumerated attribute called color can contain Red, Green or >> Blue, 2) Three different attributes called Red, Green & Blue each of >> which may be present or absent, and 3) a multi-value attribute which >> may contain the values Red, Green & Blue zero, one or more than one >> time each. >>>>> So for starters the question is whether to cover all of >> these cases or just some and what specifically should the rules be for >> each supported case. In particular is it sufficient to perform some >> test on an attribute or do we have to check for all the legal values or >> just check at least one. >>>>> Now consider the xacml policy evaluation process. A policy >> package contains a bunch of policies the PDP trusts, but just by >> looking at them it is not possible to determine which ones will be used >> for a particular decision or even if they will ever be used. Only when >> a request is processed then if the tests in the Target and Condition >> are true, the policy will be deemed applicable. Then the applicable >> policies’ Effect will be combined to produce a decision. At that point >> , that is in the context of a particular request) we have three types >> of policies: 1) Inapplicable, 2) Applicable with same Effect as the >> decision and 3) Applicable, but with a different Effect as the >> decision. >>>>> So here we need to decide do the checks of critical >> attributes in policy need to occur in Set 2 or both Set 2 and Set 3? >>>>> I believe answering these questions will clarified the >> desired functionality. >>>>> Turning to implementation, I agree it is very desirable to >> do this analysis at policy testing/deployment time not at decision time >> if at all possible. It seems a bad practice to halt all access to a >> resource because we discovered a policy bug at decision time. This >> could conceivably create a DoS attack in some environments. Further >> many environments have latency requirements for policy decisions. >>>>> The approach I mentioned last year was to perform semantic >> analysis on the policies and determine if certain information was >> checked under specified conditions. I believe it would also be possible >> to assert conditions that you believe will always true about your >> policies. This would be more general that Martins cases, but would also >> make it possible to detect policy errors. >>>>> At one point Axiomatics was offering a semantic analysis >> tool, developed by another company, to analyze policies. I don’t see it >> mentioned on their web site now, so perhaps that approach has been >> abandoned. Can Erik or David or anybody from Axiomatics comment on the >> experiences with this? >>>>> Hal >>>>> >>>>> *From:*Erik Rissanen [mailto:erik@axiomatics.com] >>>>> *Sent:* Thursday, January 07, 2016 3:54 AM >>>>> *To:* Martin Smith >>>>> *Cc:* XACML TC >>>>> *Subject:* Re: [xacml] Re: [EXTERNAL] [xacml] Default >> behavior for unrecognized resource attributes? >>>>> 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 >>>>> >>>> >>>> >>>> >>>> -- >>>> *Martin F Smith, Principal* >>>> *BFC Consulting, LLC* >>>> McLean, Va 22102 >>>> 703 506-0159 >>>> 703 389-3224 mobile >>> -- >>> Thanks, Rich >>> >>> Oracle <http://www.oracle.com> >>> Rich Levinson | Internet Standards Security Architect >>> Mobile: +1 978 5055017 <tel:+1%20978%205055017> Oracle Identity >>> Management >>> 45 Network Drive | Burlington, Massachusetts 01803 Green Oracle >>> <http://www.oracle.com/commitment> Oracle is committed to developing >>> practices and products that help protect the environment >>> >> >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS TC that >> generates this mail. Follow this link to all your TCs in OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]