RE: [xacml] Re: [EXTERNAL] [xacml] Default behavior for unrecognized resource attributes?

[Hal Lockhart <hal.lockhart@oracle.com>]

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