+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:]
>> 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 <
>> <mailto:>> 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:]
>>>>> *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:]
>>>>> *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
>
