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?

Hi Martin,

On 5/02/2016 2:51 AM, Martin Smith wrote:
Steven -- Thanks for the ideas.  After mulling it for a few days I think maintaining a separate list of MustUnderstand attribs would likely add to the complexity imposed on RPs. They would have to have a new process to make sure that if a new attrib were associated with the resource (or one removed) that the MustUnderstand attrib was also updated. Since the problem I was trying to address was lack of synch between ABAC processes (implementing digital policies "at HQ" vs maintaining appropriate resource tagging by (presumably) multiple RP programs and sites), this might actually make the problem worse.

Generally speaking, you need a way to identify the information from a resource
that is relevant for access control decisions. In XACML, information from a
resource appears as XACML attributes. I can see only two choices; either PEPs and
PIPs are constrained to present nothing other than XACML attributes corresponding
to resource information relevant to access control decisions, or there is a
separate indication of the information from the resource that is relevant to
access control decisions (possibly, but not necessarily, as a list of XACML
resource attribute identifiers).

To date, PEPs and PIPs have been written with the assumption that there is no
harm in providing XACML attributes that aren't actually necessary. In the
interests of maximizing interoperability there is a definite bias towards
providing more rather than less. Forcing PEPs and PIPs to be more circumspect
about the attributes they provide will require some re-engineering and a new way
of thinking about PEPs and PIPs and I don't see any enthusiasm in the TC for doing
that. The supposed benefit is too small compared to the cost and disruption it
will cause. That really only leaves the second choice as having any chance of
gaining enough support to become an XACML standard profile.

On the specific point, it is not necessarily the case that the MustUnderstand
attribute is manually maintained. I could build a PIP that automatically
generates the contents from local attribute definitions, but given the bias above
it is actually a good thing for existing PIPs that the MustUnderstand attribute
doesn't necessarily reflect all the locally known attributes.

I do think my original idea that it would be the PDP that would initiate the collection of "ALL" (access-type) resource attribs is probably flawed. The check required would have to (1) collect all (access-relevant) resource attribs, and then (2) compare them to the set of policies selected (via examination of the "Target" of all available policies) to be applied to the current Request, to determine if each of the resource attribs has been mentioned in at least one of those policies; and the (3) issue a Deny (or perhaps warning via Advice) that would over-ride the decision otherwise made by the PDP. What ABAC component would do this work?

If you tie things down to exactly what's in the policies you will never be
able to change their references to resource attributes. The PIPs, PEPs and
policies can't be changed simultaneously so there has to be a way to temporarily
accept old stuff while migrating to new stuff.

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

1. Agree this would be totally opt-in (a profile), except that I'd like to zero in on who exactly should be given the choice.  My perspective is the data custodian's (owner's) point of view. I think these discussions assume that there is a unified command structure covering policy makers, data custodians and ABAC deployers.  This is reasonable if all are in one organization, but perhaps needs to be clarified in cross-organizational situations.

There doesn't have to be a unified command structure, but all the components have
to cooperate and do their part. No one component can achieve your desired outcome
unilaterally. In what I suggested the "on" switch is in the policy, but there's no
point flicking it on if the PEPs and PIPs aren't ready.

2. For Steven's idea, or some variation of what I described above, to be implemented, what would the "profile" guidance consist of?  Guidance on how a Context Handler or PIP should operate? Or what?

After describing the intended purpose, the profile would define the MustUnderstand
resource attribute (needs a better name), what it is supposed to contain and the
format of its values. Optionally define an obligation or advice for conveying the
existence of a discrepancy for implementations that want a softer option to
outright Deny. At least one example of a policy and a request should be
provided to show how the profile's intended purpose can be realized. Ideally,
there would be some discussion and/or examples of how to deal with common
operational scenarios, like changing the set of significant attributes.




On Sun, Jan 31, 2016 at 11:47 PM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote:

    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


             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.


        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.


        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.



            On Fri, Jan 15, 2016 at 4:17 AM, Erik Rissanen <erik@axiomatics.com <mailto:erik@axiomatics.com> <mailto: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,

                 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?


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

                     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?


                         *From:*Erik Rissanen [mailto:erik@axiomatics.com <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?


                         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,

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


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



            *Martin F Smith, Principal*
            *BFC Consulting, LLC*
            McLean, Va 22102
            703 506-0159 <tel:703%20506-0159>
            703 389-3224 <tel:703%20389-3224> mobile

        Thanks, Rich

        Oracle <http://www.oracle.com>
        Rich Levinson | Internet Standards Security Architect
        Mobile: +1 978 5055017 <tel:%2B1%20978%205055017> <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

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