[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Making progress?
Hi Rich and All,
Great! To facilitate review, I'll write up a new working draft with
these proposed changes and post it for review. If somebody objects, let
me know.
Best regards,
Erik
Rich.Levinson wrote:
> Hi Erik,
>
> This proposal sounds good to me. Apologies for any ambiguity on my
> preference for having the biased algorithms - it took a while for me
> to realize that having "only" the unbiased algorithms made it
> impossible to screen out Indeterminates and NotApplicables - I had
> thought cleverly combining them could block things, but when I worked
> thru the details I realized that was not possible. My sense is that
> for the most part people will want to use unbiased, but that often
> there will be a need to "cap off" the hierarchy w biased so that the
> PDP actually makes the decision and doesn't leave it to the PEP. Not
> everyone will want to do this, but I think we should make it available
> for those who do.
>
> Also, I am not a strong advocate of the other 2 algorithms (5 and 6),
> however, I found it interesting "logically" to understand where they
> fit, especially since it appears the policy-permit-overrides in C.3
> was intentionally the way it was to minimize the number of Indeterminates.
>
> It causes me to think a little more about what Indeterminate(D), (P),
> (DP) really mean. These were defined in attachment to:
> http://lists.oasis-open.org/archives/xacml/200811/msg00028.html
> and from the perspective of the "-overrides" suffix, I think that
> having these algorithms (5 and 6) undermines the meaning of "-overrides".
>
> i.e. if we have a deny-overrides Policy and there are no denies,
> and we are left with a permit and a potential deny
> (Indeterminate(D)), then someone could theoretically discover that
> they were denied by this policy, but that if they simply left out
> an attribute, then that policy would evaluate to Indeterminate(D),
> which would be overridden by a Permit. I know we discussed this
> before, but I think it is worth recalling again, because it
> appears fundamentally "wrong", at least in an algorithm named
> "deny-overrides".
>
> i.e. in prev email, I pointed out that the motivation appeared to
> be to minimize Indeterminates, which, while it may sound like a
> reasonable objective, the reality of it in a combining algorithm
> really undermines the apparent intent of the algorithm.
>
> i.e. deny-overrides is very weak if you can remove the impact of
> the deny by simply submitting less information.
>
> Therefore, I agree that the algorithms 5,6 should not be something
> that we recommend in the spec. It they were to be intermingled with
> the first 4 algorithms, they could create significant confusion. If
> someone really wants them, they can always add in a custom algorithm,
> if their PDP supports that.
>
> Bottom line: I think we are in agreement w the four combining algorithms.
>
> Thanks,
> Rich
>
>
>
> Erik Rissanen wrote:
>> Hi Rich and all,
>>
>> I must have misunderstood you earlier. I thought you did not want the
>> biased algorithms. But defining them is fine for me, as long we also
>> have the unbiased ones. I think what Daniel suggests is not what most
>> people would want to do, since I don't think most people want to hide
>> errors from the PEP, but if someone would like to do that, then
>> that's up to them to define in their policy, if they can choose
>> between biased and unbiased algorithms.
>>
>> The four first algorithms Rich proposes are good and will cover most
>> use cases. The first two are for regular policy combining, number
>> three and four are useful for defining bias in a policy.
>>
>> The last two I think are dangerous and not useful. It's dangerous to
>> combine permits and denys when there are indeterminates which could
>> potentially be either permit or deny (which one is dangerous depends
>> on the algorithm). For instance, if you use deny-permit-overrides and
>> you have a Permit and Indet{D}, then the algorithm would return a
>> Permit, although there could have been a deny somewhere else, but
>> this was hidden by an error. I don't see any use case for this and it
>> could be dangerous. On the other hand, if we "fix" this problem in
>> the algorithm, the last two become the same as the first two.
>>
>> So, I propose that we define the following algorithms. (I like these
>> names slightly better than the ones Rich is using.)
>>
>> All algorithms use extended indeterminate.
>>
>> - urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides
>> This one is not biased. Basically the same thing as the 2.0 rule
>> combining alg.
>>
>> -
>> urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-overrides
>> This one is not biased. Basically the same thing as the 2.0 rule
>> combining alg.
>>
>> -
>> urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit
>>
>>
>> -
>> urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-unless-deny
>>
>>
>> Best regards,
>> Erik
>>
>> P.S. I don't think we can cover all possible combining algorithms in
>> the standard. If we disregard order and number of policies, there are
>> 16 possible inputs to a combining algorithm (the power set of the the
>> set {P,D,I,NA}). For each input, the algorithm can return one out of
>> four results. So there are a total of 4^16 different possible
>> combining algorithms. That's about 4.3 billion variants. Correct me
>> if I am mistaken. :-)
>>
>>
>> Rich.Levinson wrote:
>>> Hi Erik, and all,
>>>
>>> I have some concerns about the proposed resolution. In particular,
>>> dis-allowing the biased algorithms (the existing XACML 2.0
>>> policy-combining algorithm, deny-overrides, section C.1, is biased,
>>> explicitly because of lines 5225-5228 (if Indeterminate return
>>> Deny)) we are essentially changing what, according to Daniel, was
>>> planned functionality:
>>> http://lists.oasis-open.org/archives/xacml/200810/msg00027.html
>>>
>>> "The whole point of Indeterminate value is that it can be
>>> explicitly handled by a combining algorithm, and error propagation
>>> avoided whenever possible. Just throwing an exception all the way
>>> to the client is what we have tried to avoid."
>>>
>>> In all the discussion that followed that, from my perspective, we
>>> were trying to find a rationale for determining what the "correct"
>>> set of combining algorithms should be. In the process, we uncovered
>>> two fundamental characteristics of the existing algorithms:
>>>
>>> 1. There is an implicit "bias" property that was exhibited in
>>> policy deny-overrides (C.1), that did not have a corresponding
>>> representation policy permit-overrides (C.3). (and it also
>>> appeared that C.3 had a mistake, because a Deny was given
>>> precedence over Indeterminate in a permit-overrides algorithm,
>>> which appeared to ignore the fact that the Indeterminate is a
>>> potential-permit. Based on the text preceding the p-code, and
>>> Daniel's comment above, this may also have been intended, with
>>> the notion that any definitive decision is preferable to
>>> Indeterminate, however it appears to be a 3rd variation to the
>>> notion of "overrides".)
>>>
>>> 2. There is an implicit "extended" property (probably need a better
>>> term) that was inherent in the rule-combining algorithms that
>>> was screened out in the policy-combining algorithms. This
>>> property reflects the "half-boolean" nature of a Rule, and also
>>> possibly a collection of Rules, and also the logical property
>>> propagates up to the Policy and PolicySet levels as well.
>>> However, the property was only processed by rule-combining
>>> algorithms, which accounts for the difference between the
>>> rule-combining and policy-combining algorithms, which
>>> effectively discards potentially useful information.
>>>
>>> The suggestion I made at the end of:
>>> http://lists.oasis-open.org/archives/xacml/200811/msg00037.html
>>> which was to have 2 biased and 2 un-biased extended algorithms
>>> enables all of the functional issues above to be addressed, except
>>> possibly the "3rd variation of overrides", which could possibly add
>>> 2 more (definitive-decision overrides) algorithms if that is a
>>> desired option.
>>>
>>> The point is that the existing algorithms represent a particular
>>> logical subset of the possible logical algorithms of the implicit
>>> domains that represent a 3x2 matrix (3 override options: permit,deny
>>> and definitive-decision, and 2 bias options: unbiased, biased).
>>>
>>> In addition, the existing algorithms, do not process all the
>>> information (policy combining drops the extended Indeterminate
>>> property).
>>>
>>> The following proposal is 6 algorithms that should cover all the
>>> cases above, where these algorithms can be used at both the policy
>>> and rule levels:
>>>
>>> * extended deny-overrides (e.g. C.1 rule)
>>> * extended permit-overrides (e.g. C.3 rule)
>>> * extended biased deny-overrides (deny unless explicitly
>>> permitted) (e.g. C.1 policy)
>>> * extended biased permit-overrides (permit unless explicitly
>>> denied)
>>> * extended deny-permit-overrides (indeterminate only if no deny or
>>> permit)
>>> * extended permit-deny-overrides (indeterminate only if no permit
>>> or deny) (e.g C.3 policy)
>>>
>>> I think the above list at least makes explicit the logical options
>>> that are implicitly contained in the existing algorithms. The fact
>>> that they are all prefixed by "extended" means that the nature of
>>> Indeterminates is logically preserved, although the 2 explicitly
>>> "biased" algorithms remove this property by removing Indeterminates.
>>>
>>> With the above context in mind, my inclination is that the existing
>>> algorithms are purposefully aimed at reducing the return of
>>> Indeterminates, while at the same time attempting to preserve some
>>> aspects of the half-boolean nature of an Indeterminate from a single
>>> Rule and the potential half-boolean nature of a collection of Rules
>>> within a Policy. (However, the existing algorithms do not take into
>>> account the potential half-boolean nature of a Policy, PolicySet, or
>>> collections of Policies and PolicySets.)
>>>
>>> Therefore, I am very reluctant to agree that we should only include
>>> unbiased algorithms.
>>>
>>> One final point to the comment in Erik's email:
>>>
>>> "Currently this means that policies have to be refactored so that
>>> all such rules are isolated in their own policy since rules cannot
>>> contain obligations directly. This is a bit of nuisance to do."
>>>
>>> I do not believe that with the existing algorithms that policies
>>> "can" be refactored to allow the rules to appear in their own
>>> policies, because the rules are subject to rule combining algorithms
>>> which contain logic not available in the policy combining
>>> algorithms. It is only by using the extended combining algorithms
>>> that this refactoring is possible.
>>>
>>> Thanks,
>>> Rich
>>>
>>>
>>>
>>>
>>>
>>> Erik Rissanen wrote:
>>>> Hi Rich, and all,
>>>>
>>>> It was noted during the discussion that it may be the case that one
>>>> writes a number of rules with conditions, such that if those
>>>> conditions trigger, there should be an obligation. Currently this
>>>> means that policies have to be refactored so that all such rules
>>>> are isolated in their own policy since rules cannot contain
>>>> obligations directly. This is a bit of nuisance to do.
>>>>
>>>> There was some discussion that there is really no fundamental
>>>> reason to allow obligations at the rule level. I have thought the
>>>> same thing previously, and I think it would be a good idea to allow
>>>> obligations in rules as well. At first I was opposed to the change
>>>> since we have a feature freeze and we should focus on closing
>>>> issues rather than opening new ones. But I think this is a minor
>>>> change which could be made.
>>>>
>>>> TC: what is the general opinion on this? Should we change the
>>>> schema so rules can contain obligations as well? It would be good
>>>> if I could get a general indication of what we want to decide, and
>>>> I could prepare a draft for review this week already, so we could
>>>> close this issue on the next call already. Otherwise we will make
>>>> the decision on the next call, and I edit the daft after that and
>>>> the final closing of the issue is pushed past the holidays,
>>>> delaying everything by a month or so.
>>>>
>>>> Also, could I get some kind of indication on what we want to do
>>>> regarding policy combination? After the discussions Rich and I have
>>>> had, I propose the following, which I think Rich and I at least
>>>> would agree on:
>>>>
>>>> - The regular XACML combining algorithms will not be biased.
>>>>
>>>> - We make use of the "extended indeterminate" to have better error
>>>> handling capability at the policy combining level. This also makes
>>>> the rule and policy combining algorithms symmetric.
>>>>
>>>> - We do not specify biased variants of the combining algorithms?
>>>>
>>>> TC: Could I get a rough indication on what people feel on this
>>>> issue? If so I could finish a working draft this week which can be
>>>> reviewed for CD status on the next meeting.
>>>>
>>>> Best regards,
>>>> Erik
>>>>
>>>>
>>>> Rich.Levinson wrote:
>>>>> Hi Erik,
>>>>>
>>>>> Unfortunately I missed the meeting this morning, however, Hal
>>>>> filled me in on some details. In particular, Hal mentioned that in
>>>>> the Boeing presentation that there was indicated a requirement for
>>>>> having Obligations available at the Rule level, while they are
>>>>> currently available only at the Policy level. This was also
>>>>> mentioned in today's minutes, but it is not clear from the minutes
>>>>> or a quick read of the presentation referred to in the minutes
>>>>> what the exact requirements are:
>>>>> http://lists.oasis-open.org/archives/xacml/200812/msg00008.html
>>>>> In any event, based on the partial information, I will take a stab
>>>>> at a possible means to address this issue.
>>>>>
>>>>> One aspect of the discussion on issue 66 is that we agreed there
>>>>> is essentially an "extra layer" in the PolicySet/Policy/Rule
>>>>> hierarchy, which can effectively be removed using the uniform
>>>>> extended combining algorithms we discussed in earlier emails:
>>>>> http://lists.oasis-open.org/archives/xacml/200811/msg00040.html
>>>>>
>>>>> As a result of this uniformity, there is no longer any compelling
>>>>> reason to have more than one Rule in a Policy. i.e. if you have n
>>>>> Rules in a Policy and decide you want "1-rule" Policies, then you
>>>>> can simply change the parent Policy to a PolicySet and replace
>>>>> each Rule with a Policy containing only that Rule. This will
>>>>> enable one to effectively apply Obligations at the Rule level
>>>>> since all you need to do is apply the Obligations to the Policy
>>>>> containing the single Rule.
>>>>>
>>>>> I am not sure if that addresses the requirements as stated at
>>>>> today's meeting, but would be interested to know if it does, or if
>>>>> there are additional requirements that this would not cover.
>>>>>
>>>>> Thanks,
>>>>> Rich
>>>>>
>>>>>
>>>>> Erik Rissanen wrote:
>>>>>> All,
>>>>>>
>>>>>> Could we get some more discussion on the open issues on the list
>>>>>> so I could write up a tentative working draft in good time before
>>>>>> the next meeting?
>>>>>>
>>>>>> Having long technical discussions on the calls only is very
>>>>>> inefficient. During the call today we spent 50 minutes discussing
>>>>>> a single issue, and we had an almost as long discussion on the
>>>>>> same issue last time. It would be much better if we could have
>>>>>> more discussion on the list so we can make more decisions on the
>>>>>> TC calls. Going like this means that we have many more months
>>>>>> before we have a committee draft.
>>>>>>
>>>>>> If I can get a rough direction on the following issues, I can
>>>>>> edit the specs for review before the next meeting so we can
>>>>>> hopefully approve them on the next call. Otherwise the whole
>>>>>> thing is going to slip into the holidays and get delayed even more.
>>>>>>
>>>>>> - Issue #66: policy combining. Should we fix the combining
>>>>>> algorithm bias and should we extend the indeterminate?
>>>>>>
>>>>>> - The small issues in the SAML profile. Can I get feedback on
>>>>>> them? Hal has promised to fix the wording of the returned request
>>>>>> in the SAML XACML Authz response.
>>>>>>
>>>>>> - I also propose that we extend the schema so a Rule can contain
>>>>>> obligations in the same way as Policies/PolicySets. This means
>>>>>> that we avoid the need of rewriting rules into policies in some
>>>>>> cases.
>>>>>>
>>>>>> Best regards,
>>>>>> Erik
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> 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]