OASIS eXtensible Access Control Markup Language (XACML) TC

Back to discussions
Expand all | Collapse all

Posted WD-19 of core and WD-14 of SAML profile

  • 1.  Posted WD-19 of core and WD-14 of SAML profile

    Posted 04-14-2011 17:18
    All, I have just uploaded XACML 3.0 core WD 19 and SAML profile WD 14. The fixes are for the recently found issues in CS-01: 1. CORE: Missing functions for the new dayTimeDuration and yearMonthDuration datatypes See http://lists.oasis-open.org/archives/xacml-comment/201012/msg00000.html The missing functions have been added and the old ones moved to planned for deprecation. 2. SAML: Inappropriate use of xsi:type in SAML profile protocol schemas See http://lists.oasis-open.org/archives/xacml-comment/201012/msg00001.html The schema has been corrected. Note that there is also a new spec document since the namespaces were changed. I also changed the assertion schemas although there were no errors in them, but just to make the “wd-14” in the namespaces the same. I figured that unless I do that, somebody is going to ask about it… 3. CORE: The x500Name-match function is not clearly defined http://lists.oasis-open.org/archives/xacml-comment/201101/msg00005.html I added an example. 4. CORE: Inconsistent definition for the any-of-all function See http://lists.oasis-open.org/archives/xacml-comment/201101/msg00006.html I removed the Haskell stuff. 5. This issue intentionally left blank. 6. CORE: Specification of extended indeterminate in combining algorithms is incomplete See http://lists.oasis-open.org/archives/xacml-comment/201103/msg00000.html I added the missing specifications as discussed on last week's meeting. 7. CORE: Erratum concerning the 'Expression Substitution Group' See http://lists.oasis-open.org/archives/xacml/201103/msg00036.html I removed the <Condition> element from this list. 8. CORE: Obligations problem See http://lists.oasis-open.org/archives/xacml/201103/msg00037.html I changed the wording as suggested by Greg. 9. CORE: Incomplete definition of the ipAddress-is-in and dnsName-is-in functions See http://lists.oasis-open.org/archives/xacml-comment/201103/msg00006.html I removed these functions. Note that the other higher order functions were not defined for these data types anyway. They would have had the same issue. 10. CORE: Which argument is subtracted from the other by the integer-subtract function? See: http://lists.oasis-open.org/archives/xacml-comment/201103/msg00008.html I specified the order which is used in the 2.0 conformance tests. 11. CORE: Non-deterministic output of the string-from-type functions See http://lists.oasis-open.org/archives/xacml-comment/201103/msg00007.html I used the XSD canonical form where available, otherwise specified the form from the original XML encoding. Note, I also updated many other functions which also depended on datatype to string conversion. BTW, one of the functions was uri equals, and I checked the spec for XML namespaces, which depends heavily on uri equality testing, and they do the same as we, namely just compare the string representation straight, without any kind of interpretation or canonicalization of the URIs. Best regards, Erik


  • 2.  Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of core and WD-14 of SAML profile]

    Posted 04-19-2011 15:00
    Erik, good job on the spec. I have some misgivings about the "extended indeterminate" solution for policy[set] targets. When a policy or policy-set target evaluates to Indeterminate, are we saying that the PDP must still evaluate the children and apply the combining-algorithm? I think that will result in a lot of extra evaluation for marginal benefits. At the root of the "extended indeterminate" problem for policy targets is the question: are we returning the possible indeterminate values that could result from evaluating the policy in *this* request context, or in *any possible* request context. The 1st answer requires much more sophisticated processing (and might be undecidable in some cases); the 2nd answer can be determined simply by getting the unique values of the descendant Rule/@Effect attributes (including those reachable by policy references). Perhaps the "extended indeterminate" range of values should include an "Indeterminate{U}" value, interpreted as "it is unknown whether either a Deny or a Permit could be returned". The default "Indeterminate{DP}" value says "it is certain that either a Permit or a Deny decision could be returned". If this value bubbles up from rule evaluations, it is legitimate and perhaps helpful. But if it comes from a policy target, it is ambiguous. We should reconsider whether to require full evaluation of policies or policy sets when the target is Indeterminate. As a possible evaluation shortcut, we could specify returning an extended indeterminate value based on the descendant Rule/@Effect values, without requiring full evaluation. If the new sections 7.11, 7.12, and 7.13 stand as is, there are some additional editorial changes to make, but I will save those pending result of discussion. Regards, --Paul
    Original Message


  • 3.  Re: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of coreand WD-14 of SAML profile]

    Posted 04-19-2011 18:56
    Hi Paul, I thought about the same issue. I think this is the most correct interpretation of the extended indeterminate values and their meaning. Just parsing the tree for effect might give unsafe results. Olav Bandmann did some intereting analysis on the legacy combining algorithms a few years ago, and I am afraid something similar might become an issue in a more simplified processing model. And I figured that Indeterminates are not a normal case anyway, so it's unlikely that the extra overhead is going to have any real world impact. Best regards, Erik On 2011-04-19 17:00, Tyson, Paul H wrote: > Erik, good job on the spec. > > I have some misgivings about the "extended indeterminate" solution for > policy[set] targets. > > When a policy or policy-set target evaluates to Indeterminate, are we > saying that the PDP must still evaluate the children and apply the > combining-algorithm? I think that will result in a lot of extra > evaluation for marginal benefits. > > At the root of the "extended indeterminate" problem for policy targets > is the question: are we returning the possible indeterminate values that > could result from evaluating the policy in *this* request context, or in > *any possible* request context. The 1st answer requires much more > sophisticated processing (and might be undecidable in some cases); the > 2nd answer can be determined simply by getting the unique values of the > descendant Rule/@Effect attributes (including those reachable by policy > references). > > Perhaps the "extended indeterminate" range of values should include an > "Indeterminate{U}" value, interpreted as "it is unknown whether either a > Deny or a Permit could be returned". The default "Indeterminate{DP}" > value says "it is certain that either a Permit or a Deny decision could > be returned". If this value bubbles up from rule evaluations, it is > legitimate and perhaps helpful. But if it comes from a policy target, > it is ambiguous. > > We should reconsider whether to require full evaluation of policies or > policy sets when the target is Indeterminate. As a possible evaluation > shortcut, we could specify returning an extended indeterminate value > based on the descendant Rule/@Effect values, without requiring full > evaluation. > > If the new sections 7.11, 7.12, and 7.13 stand as is, there are some > additional editorial changes to make, but I will save those pending > result of discussion. > > Regards, > --Paul > > > >
    Original Message


  • 4.  RE: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of core and WD-14 of SAML profile]

    Posted 04-19-2011 21:57
    Erik, I see your point. But then we would force everyone to deal with extended indeterminate values, even if they don't use any of the 3.0 algorithms that rely on them. That doesn't sound right. Logically, a policy with a target is equivalent to a policy with the target element transformed to an Apply expression and conjunctively appended to the Condition of all descendant Rules. So the result of evaluating a policy with an indeterminate target should be the same as the result of evaluating the re-written policy (with no target) as if all rules returned "Indeterminate". For Policy evaluation, this could be specified like: "When the Target value is Indeterminate, the result of the policy shall be determined by applying the rule-combining-algorithm to the child Rules, while using "Indeterminate" as the fixed return value from each Rule evaluated." For PolicySet evaluation: "When the Target value is Indeterminate, the result of the policy set shall be determined by applying the policy-combining-algorithm to the child policies and policysets, while using "Indeterminate" as the fixed return value from each Rule evaluated." In either case it is not necessary that the implementation actually evaluate the children--only that the results are identical to that procedure. Regards, --Paul
    Original Message


  • 5.  Re: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of coreand WD-14 of SAML profile]

    Posted 04-20-2011 11:21
    Paul, See inline. On 2011-04-19 23:57, Tyson, Paul H wrote: > Erik, > > I see your point. But then we would force everyone to deal with > extended indeterminate values, even if they don't use any of the 3.0 > algorithms that rely on them. That doesn't sound right. The 3.0 algorithms are mandatory to implement, so they have to be dealt with anyway. In any case, if an implementation should choose to skip those algorithms, they can easily also skip anything to do with {D}, {P} and {DP}. So I would not worry about this. > Logically, a policy with a target is equivalent to a policy with the > target element transformed to an Apply expression and conjunctively > appended to the Condition of all descendant Rules. So the result of > evaluating a policy with an indeterminate target should be the same as > the result of evaluating the re-written policy (with no target) as if > all rules returned "Indeterminate". No, this is not true. Currently the tables in the spec specify that if the target is Indeterminate, then the policy is Indeterminate (of some extended type). Transforming the policy like you say, would not lead to the same result in general since the combining algorithm is in principle free to do whatever with the Indeterminate from the rules. In fact, some of the 2.0 policy combining algorithms convert an Indeterminate to a Deny. So this transformed policy is not equivalent to the original policy in general. Best regards, Erik > For Policy evaluation, this could be specified like: "When the Target > value is Indeterminate, the result of the policy shall be determined by > applying the rule-combining-algorithm to the child Rules, while using > "Indeterminate" as the fixed return value from each Rule evaluated." > > For PolicySet evaluation: "When the Target value is Indeterminate, the > result of the policy set shall be determined by applying the > policy-combining-algorithm to the child policies and policysets, while > using "Indeterminate" as the fixed return value from each Rule > evaluated." > > In either case it is not necessary that the implementation actually > evaluate the children--only that the results are identical to that > procedure. > > Regards, > --Paul > >
    Original Message


  • 6.  RE: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of core and WD-14 of SAML profile]

    Posted 04-20-2011 13:19
    I agree that conventional usage and interpretation of the spec could support this view (i.e., that a policy with a target should not always give the same result as a policy with the target matching conditions distributed to rules). I'm saying that this is a logical inconsistency that we might want to consider fixing, rather than adding more special evaluation procedures. In either case, this sentence in Section 5.6 cannot stand as is: "For the parent of the <Target> element to be applicable to the decision request, there MUST be at least one positive match between each <AnyOf> element of the <Target> element and the corresponding section of the <Request> element." This would imply that policies with indeterminate targets must always return "NotApplicable". Regards, --Paul
    Original Message


  • 7.  Re: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of coreand WD-14 of SAML profile]

    Posted 04-20-2011 14:00
    Hi Paul, See inline. On 2011-04-20 15:19, Tyson, Paul H wrote: > I agree that conventional usage and interpretation of the spec could > support this view (i.e., that a policy with a target should not always > give the same result as a policy with the target matching conditions > distributed to rules). > > I'm saying that this is a logical inconsistency that we might want to > consider fixing, rather than adding more special evaluation procedures. I don't think this is a logical inconsistency. It has to be like this or otherwise many of the current combining algorithms could not be implemented. For instance the deny-unless permit also converts, intentionally, Indeterminates to Denys. "The target evaluates to Indeterminate, so we do not know whether this policy applies" is not the same thing as "all rules in this policy are broken and return Indeterminate". In the latter case the policy combining algorithm could override the rules and return something else than Indeterminate. > In either case, this sentence in Section 5.6 cannot stand as is: > > "For the parent of the<Target> element to be applicable to the decision > request, there MUST be at least one positive match between each<AnyOf> > element of the<Target> element and the corresponding section of the > <Request> element." > > This would imply that policies with indeterminate targets must always > return "NotApplicable". Well, I guess this is true. And I guess there are lots of other cases like this in the text. The problem is that there are three places with normative descriptions for target evaluation, for instance. The tables in the evaluation section, the text in the evaluation section and finally the text in the schema fragments section. I am also saying that the way the text is written in human language, it will never be perfect. But the meaning should be clear from the context. > Regards, > --Paul > >
    Original Message


  • 8.  RE: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of core and WD-14 of SAML profile]

    Posted 04-20-2011 18:53
    See below. >
    Original Message


  • 9.  Re: Indeterminate Policy Targets [WAS: [xacml] Posted WD-19 of coreand WD-14 of SAML profile]

    Posted 04-21-2011 08:14
    Paul, I believe the intent has always been "2", that is a target is not just syntactic sugar. But I joined after 2.0 was done, so I cannot say for sure. In any case, that is what I think it should be. It is also what the spec unambiguously specifies because the evaluation tables are as they are. (Sure, the spec does not say explicitly that it "1" is not intended, but that's good. I don't think we should be specifying what the spec is not. ;-)) Anyway, I appreciate the analysis, but I think it's good as it is. I also agree with you Paul that the "deny-unless-permit" and "permit-unless-deny" algorithms are very bad practice. But some like them, so that's their concern. ;-) Best regards, Erik On 2011-04-20 20:52, Tyson, Paul H wrote: > See below. > >>
    Original Message


  • 10.  Re: [xacml] Indeterminate Policy Targets [WAS: [xacml] Posted WD-19of core and WD-14 of SAML profile]

    Posted 04-19-2011 18:56
    Hi Paul, A quick response is that it is basically the same as the rule combining algorithms. For example, in a deny-overrides policy, you have to continue evaluating policies until you either: - find a deny, - or a permit with no deny (basically all permits), - or a permit and an indeterminate, which results in indeterminate. The only way to avoid evaluating all policies is if you encounter a deny, then you know the answer regardless of what the other policies might return. If the Target of the current PolicySet is Indeterminate, then I expect one would immediately return Indeterminate w/o evaluating the children, since they are all predicated on successful evaluation of the Target. This is distinct from the case where say there is a parent PolicySet that has n child PolicySets, then if one of the child PolicySets is Indeterminate, then you still need to evaluate the other child PolicySets using the algorithm above, where the breakout point depends on what the combining algorithm and the current set of child results imply at that point. Finally, I don't think finding Indeterminate in the parent PolicySet Target is ambiguous, because you would then look at the possible responses from its children and if they were only Permits it would be Ind(P), if they were only Denys then it would be Ind(D), and a mix would be Ind(DP). I don't think there is much point in this last case of actually evaluating the child Policies after the parent Target is Indeterminate, but there is a purpose in "scanning" them to determine what their possible returns would have been. Thanks, Rich On 4/19/2011 11:00 AM, Tyson, Paul H wrote: > Erik, good job on the spec. > > I have some misgivings about the "extended indeterminate" solution for > policy[set] targets. > > When a policy or policy-set target evaluates to Indeterminate, are we > saying that the PDP must still evaluate the children and apply the > combining-algorithm? I think that will result in a lot of extra > evaluation for marginal benefits. > > At the root of the "extended indeterminate" problem for policy targets > is the question: are we returning the possible indeterminate values that > could result from evaluating the policy in *this* request context, or in > *any possible* request context. The 1st answer requires much more > sophisticated processing (and might be undecidable in some cases); the > 2nd answer can be determined simply by getting the unique values of the > descendant Rule/@Effect attributes (including those reachable by policy > references). > > Perhaps the "extended indeterminate" range of values should include an > "Indeterminate{U}" value, interpreted as "it is unknown whether either a > Deny or a Permit could be returned". The default "Indeterminate{DP}" > value says "it is certain that either a Permit or a Deny decision could > be returned". If this value bubbles up from rule evaluations, it is > legitimate and perhaps helpful. But if it comes from a policy target, > it is ambiguous. > > We should reconsider whether to require full evaluation of policies or > policy sets when the target is Indeterminate. As a possible evaluation > shortcut, we could specify returning an extended indeterminate value > based on the descendant Rule/@Effect values, without requiring full > evaluation. > > If the new sections 7.11, 7.12, and 7.13 stand as is, there are some > additional editorial changes to make, but I will save those pending > result of discussion. > > Regards, > --Paul > > > >
    Original Message


  • 11.  Re: [xacml] Indeterminate Policy Targets [WAS: [xacml] Posted WD-19of core and WD-14 of SAML profile]

    Posted 04-19-2011 18:59
    Hi Rich, See inline. On 2011-04-19 20:55, rich levinson wrote: > Hi Paul, > > A quick response is that it is basically the same as the rule > combining algorithms. > For example, in a deny-overrides policy, you have to continue > evaluating policies > until you either: > - find a deny, > - or a permit with no deny (basically all permits), > - or a permit and an indeterminate, which results in indeterminate. > The only way to avoid evaluating all policies is if you encounter a > deny, then > you know the answer regardless of what the other policies might return. > > If the Target of the current PolicySet is Indeterminate, then I expect > one > would immediately return Indeterminate w/o evaluating the children, since > they are all predicated on successful evaluation of the Target. Yes, but the question is which type of Indeterminate? {P}, {D} or {DP}? This was the issue which was posted on the comments list. > > This is distinct from the case where say there is a parent PolicySet > that has > n child PolicySets, then if one of the child PolicySets is > Indeterminate, then > you still need to evaluate the other child PolicySets using the > algorithm above, > where the breakout point depends on what the combining algorithm and the > current set of child results imply at that point. > > Finally, I don't think finding Indeterminate in the parent PolicySet > Target is > ambiguous, because you would then look at the possible responses from > its children and if they were only Permits it would be Ind(P), if they > were > only Denys then it would be Ind(D), and a mix would be Ind(DP). > > I don't think there is much point in this last case of actually > evaluating the > child Policies after the parent Target is Indeterminate, but there is > a purpose > in "scanning" them to determine what their possible returns would have > been. > This is what Paul is proposing, but I think what I wrote is safer. See my other response to Paul. Best regards, Erik > Thanks, > Rich > > > On 4/19/2011 11:00 AM, Tyson, Paul H wrote: >> Erik, good job on the spec. >> >> I have some misgivings about the "extended indeterminate" solution for >> policy[set] targets. >> >> When a policy or policy-set target evaluates to Indeterminate, are we >> saying that the PDP must still evaluate the children and apply the >> combining-algorithm? I think that will result in a lot of extra >> evaluation for marginal benefits. >> >> At the root of the "extended indeterminate" problem for policy targets >> is the question: are we returning the possible indeterminate values that >> could result from evaluating the policy in *this* request context, or in >> *any possible* request context. The 1st answer requires much more >> sophisticated processing (and might be undecidable in some cases); the >> 2nd answer can be determined simply by getting the unique values of the >> descendant Rule/@Effect attributes (including those reachable by policy >> references). >> >> Perhaps the "extended indeterminate" range of values should include an >> "Indeterminate{U}" value, interpreted as "it is unknown whether either a >> Deny or a Permit could be returned". The default "Indeterminate{DP}" >> value says "it is certain that either a Permit or a Deny decision could >> be returned". If this value bubbles up from rule evaluations, it is >> legitimate and perhaps helpful. But if it comes from a policy target, >> it is ambiguous. >> >> We should reconsider whether to require full evaluation of policies or >> policy sets when the target is Indeterminate. As a possible evaluation >> shortcut, we could specify returning an extended indeterminate value >> based on the descendant Rule/@Effect values, without requiring full >> evaluation. >> >> If the new sections 7.11, 7.12, and 7.13 stand as is, there are some >> additional editorial changes to make, but I will save those pending >> result of discussion. >> >> Regards, >> --Paul >> >> >> >>
    Original Message


  • 12.  Re: [xacml] Indeterminate Policy Targets [WAS: [xacml] Posted WD-19of core and WD-14 of SAML profile]

    Posted 04-19-2011 19:59
    Hi Erik, I will pull up your responses for ease of readability: 1. Yes, but the question is which type of Indeterminate? {P}, {D} or {DP}? This was the issue which was posted on the comments list. I was addressing Paul's concern that: When a policy or policy-set target evaluates to Indeterminate, are we saying that the PDP must still evaluate the children and apply the combining-algorithm?  I think that will result in a lot of extra evaluation for marginal benefits. I was trying to say that the amount of evaluation that needed to take place depended on the combining algorithm and the possible values that had been returned and that this evaluation strategy was the same for Rules, Policys, and PolicySets, at least with the extended algorithms. I then went on to discuss the explicit case of a Target indeterminate, and what potential impact that had on evaluating the children, and I said it was the same as if the first child evaluated to Indeterminate, one still needed to look at the combining alg and the results as one progressed to determine the first possible unambiguous break out time. 2. This is what Paul is proposing, but I think what I wrote is safer. See my other response to Paul. I don't see how what I was proposing , which was not a proposal, but an explanation of how it currently operates, at least, as I interpret it, could be in any way compared to Paul's proposal which recommended a change. As far as which type of Indeterminate to return to a XACML 2.0 environment, I think your proposed language addresses the problem properly, namely that you just drop the qualifier, and 2.0 can proceed w/o taking advantage of the additional information that is possible in 3.0 but not in 2.0 as specified.     Thanks,     Rich On 4/19/2011 2:58 PM, Erik Rissanen wrote: 4DADDB71.6090704@axiomatics.com type= cite >Hi Rich, See inline. On 2011-04-19 20:55, rich levinson wrote: Hi Paul, A quick response is that it is basically the same as the rule combining algorithms. For example, in a deny-overrides policy, you have to continue evaluating policies until you either:      - find a deny,      - or a permit with no deny (basically all permits),      - or a permit and an indeterminate, which results in indeterminate. The only way to avoid evaluating all policies is if you encounter a deny, then you know the answer regardless of what the other policies might return. If the Target of the current PolicySet is Indeterminate, then I expect one would immediately return Indeterminate w/o evaluating the children, since they are all predicated on successful evaluation of the Target. Yes, but the question is which type of Indeterminate? {P}, {D} or {DP}? This was the issue which was posted on the comments list. This is distinct from the case where say there is a parent PolicySet that has n child PolicySets, then if one of the child PolicySets is Indeterminate, then you still need to evaluate the other child PolicySets using the algorithm above, where the breakout point depends on what the combining algorithm and the current set of child results imply at that point. Finally, I don't think finding Indeterminate in the parent PolicySet Target is ambiguous, because you would then look at the possible responses from its children and if they were only Permits it would be Ind(P), if they were only Denys then it would be Ind(D), and a mix would be Ind(DP). I don't think there is much point in this last case of actually evaluating the child Policies after the parent Target is Indeterminate, but there is a purpose in scanning them to determine what their possible returns would have been. This is what Paul is proposing, but I think what I wrote is safer. See my other response to Paul. Best regards, Erik     Thanks,     Rich On 4/19/2011 11:00 AM, Tyson, Paul H wrote: Erik, good job on the spec. I have some misgivings about the extended indeterminate solution for policy[set] targets. When a policy or policy-set target evaluates to Indeterminate, are we saying that the PDP must still evaluate the children and apply the combining-algorithm?  I think that will result in a lot of extra evaluation for marginal benefits. At the root of the extended indeterminate problem for policy targets is the question: are we returning the possible indeterminate values that could result from evaluating the policy in *this* request context, or in *any possible* request context.  The 1st answer requires much more sophisticated processing (and might be undecidable in some cases); the 2nd answer can be determined simply by getting the unique values of the descendant Rule/@Effect attributes (including those reachable by policy references). Perhaps the extended indeterminate range of values should include an Indeterminate{U} value, interpreted as it is unknown whether either a Deny or a Permit could be returned .  The default Indeterminate{DP} value says it is certain that either a Permit or a Deny decision could be returned .  If this value bubbles up from rule evaluations, it is legitimate and perhaps helpful.  But if it comes from a policy target, it is ambiguous. We should reconsider whether to require full evaluation of policies or policy sets when the target is Indeterminate.  As a possible evaluation shortcut, we could specify returning an extended indeterminate value based on the descendant Rule/@Effect values, without requiring full evaluation. If the new sections 7.11, 7.12, and 7.13 stand as is, there are some additional editorial changes to make, but I will save those pending result of discussion. Regards, --Paul
    Original Message


  • 13.  RE: [xacml] Posted WD-19 of core and WD-14 of SAML profile

    Posted 04-19-2011 15:59
    Minor corrections on lines 4561 and 4572: duplicate word "string". (Line numbers from "Final Showing Markup" view.) Regards, --Paul
    Original Message


  • 14.  Re: [xacml] Posted WD-19 of core and WD-14 of SAML profile

    Posted 04-19-2011 18:58
    Hi Paul, Thanks. Could we let this one slip? /Erik On 2011-04-19 17:58, Tyson, Paul H wrote: > Minor corrections on lines 4561 and 4572: duplicate word "string". (Line > numbers from "Final Showing Markup" view.) > > Regards, > --Paul > >
    Original Message


Related Content