为什么需要 PolicySet 和 Policy?
Why both PolicySet and Policy are needed?
我已经通读了 3.0 规范并在这里有一个问题:
我发现 PolicySet 和 Policy 有许多相似之处,例如组合算法等。为了容纳更多级别,PolicySet 也可以是独立的。如果是这样,为什么不将 PolicySet 和 Policy 合并到一个名为 Policy 的概念中,并使 Policy 包含其他政策和规则?
更新:
说到Rule,其实Rule和Policy也没什么区别,除了 Rule 有 Condition 和 Effect 并且没有 combining 算法。我现在想的是将PolicySet、Policy、Rule这三个概念合并成一个新的Policy。此政策 是独立的,可以有其条件 和效果。如果它的组合算法returns中级,那么就用它自己的效果。如果自身的条件不满足要求,则整个政策不适用。我个人认为这种单一概念模型比PolicySet、Policy和Rule更简洁明了。
例如,对于四级策略(如果大企业有四级策略的需求),XACML将表示为:
PolicySet -> PolicySet(s) -> Policy(s) -> Rule(s)
我的修改是:
Policy -> Policy(s) -> Policy(s) -> Policy(s)
与 XACML 的两级策略集和一级策略和规则相比,我认为直接的四级策略会是更清晰?
两者都存在的事实是语言的一个怪癖。您可以想象一种具有叶元素(规则)和分支(策略)的语言。
Policy 和 PolicySet 非常相似。在 XACML 中建模时,您可以吸收它们。
您的策略可以包含其他策略 XOR 规则,但不能同时包含两者
编辑
在 OP 的编辑之后,这里有更多的上下文。
XACML 结构元素
XACML 引入了 3 个结构元素:
- 政策集(PS)
- 政策 (P)
- 规则 (R)
正如 OP 所述,PolicySet 可以包含 Policy 和 PolicySet,从而允许整个树的深度与作者希望的一样深(PS --> PS --> PS ... --> P --> R).
策略集、策略和规则的内容
所有三个元素(PS、P、R)可以包含:
- 目标元素:目标是定义元素范围的东西。目标由 AND/OR/AND 结构和属性匹配组成,例如
role=='manager' OR role=='editor'
.
- 义务和建议:义务和建议是 return 与从 PDP(策略决策点)返回 PEP(策略执行点)的决定一起编辑的声明
组合算法
因为 PolicySet 和 Policy 元素可以包含子元素,所以它们需要一种机制来解决子元素之间的冲突。该机制称为组合算法。因此,PolicySet 元素和 Policy 元素都有一个组合算法 属性。由于 PolicySet 包含其他 PolicySet and/or 个策略元素,因此 PolicySet 中的组合算法称为 策略组合算法 。由于策略元素只包含规则,所以组合算法称为规则组合算法。
XACML 的另一个怪癖是策略的组合算法列表几乎与规则相同。显着差异是:
- only-one-applicable 仅适用于策略。
- on-permit-apply-second 仅适用于策略。
这是 ALFA notation (ALFA is a pseudo-language developed by Axiomatics 中用于简化 XACML 策略编写的列表):
namespace System {
ruleCombinator denyOverrides = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides"
ruleCombinator permitOverrides = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-overrides"
ruleCombinator firstApplicable = "urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
ruleCombinator orderedDenyOverrides = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-deny-overrides"
ruleCombinator orderedPermitOverrides = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-permit-overrides"
ruleCombinator denyUnlessPermit = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit"
ruleCombinator permitUnlessDeny = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-unless-deny"
policyCombinator denyOverrides = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides"
policyCombinator permitOverrides = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-overrides"
policyCombinator firstApplicable = "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable"
policyCombinator onlyOneApplicable = "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable"
policyCombinator orderedDenyOverrides = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-deny-overrides"
policyCombinator orderedPermitOverrides = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-permit-overrides"
policyCombinator denyUnlessPermit = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit"
policyCombinator permitUnlessDeny = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-unless-deny"
policyCombinator onPermitApplySecond = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:on-permit-apply-second"
}
目标和条件
目标
如前所述,Target 元素可以存在于 PolicySet、Policy 和 Rule 中的任何一个中。目标具有 AND/OR/AND 元素的集合结构,用于将属性匹配组合在一起,即给定属性与给定值的比较。 XACML 提供了一长串可以使用的函数。
在目标中,只能使用具有 2 个原子值的函数,并且 return 可以使用布尔值,例如==(或 urn:oasis:names:tc:xacml:1.0:function:string-equal)。其他功能,例如sum (urn:oasis:names:tc:xacml:1.0:function:integer-add) 不能使用。
条件
特别是,有一件非常有用 目标元素不能做的事情:比较两个属性,即建立关系。想象一下,例如你想写一个声明的政策:
Doctors can view the medical record of a patient they are assigned to.
或者换句话说,Permit if userId == assignedDoctorId
。
这是 Condition 元素发挥作用的地方。Condition 是一个表达式,可以使用 XACML 中可用的任何函数。条件的总体结果必须是布尔值,但现在您可以执行 sum(age, limit)>5
或 userId == assignedDoctorId
.
之类的操作
还有一个怪癖:条件元素只能在规则元素内使用。因此,如果您想在 XACML 中表达一种关系,您将需要至少有一个规则。并且由于 Rule 元素不能独立存在。您必须至少有一项政策要素。
所以最小可能的 XACML 策略是(使用 ALFA):
namespace example{
policy policyExample{
apply denyOverrides
rule allowAll{
permit
}
}
}
生成的 XACML XML 代码为:
<?xml version="1.0" encoding="UTF-8"?>
<!--This file was generated by the ALFA Plugin for Eclipse from Axiomatics AB (http://www.axiomatics.com).
Any modification to this file will be lost upon recompilation of the source ALFA file-->
<xacml3:Policy xmlns:xacml3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
PolicyId="http://axiomatics.com/alfa/identifier/example.policyExample"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides"
Version="1.0">
<xacml3:Description />
<xacml3:PolicyDefaults>
<xacml3:XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</xacml3:XPathVersion>
</xacml3:PolicyDefaults>
<xacml3:Target />
<xacml3:Rule
Effect="Permit"
RuleId="http://axiomatics.com/alfa/identifier/example.policyExample.allowAll">
<xacml3:Description />
<xacml3:Target />
</xacml3:Rule>
</xacml3:Policy>
我已经通读了 3.0 规范并在这里有一个问题:
我发现 PolicySet 和 Policy 有许多相似之处,例如组合算法等。为了容纳更多级别,PolicySet 也可以是独立的。如果是这样,为什么不将 PolicySet 和 Policy 合并到一个名为 Policy 的概念中,并使 Policy 包含其他政策和规则?
更新:
说到Rule,其实Rule和Policy也没什么区别,除了 Rule 有 Condition 和 Effect 并且没有 combining 算法。我现在想的是将PolicySet、Policy、Rule这三个概念合并成一个新的Policy。此政策 是独立的,可以有其条件 和效果。如果它的组合算法returns中级,那么就用它自己的效果。如果自身的条件不满足要求,则整个政策不适用。我个人认为这种单一概念模型比PolicySet、Policy和Rule更简洁明了。
例如,对于四级策略(如果大企业有四级策略的需求),XACML将表示为:
PolicySet -> PolicySet(s) -> Policy(s) -> Rule(s)
我的修改是:
Policy -> Policy(s) -> Policy(s) -> Policy(s)
与 XACML 的两级策略集和一级策略和规则相比,我认为直接的四级策略会是更清晰?
两者都存在的事实是语言的一个怪癖。您可以想象一种具有叶元素(规则)和分支(策略)的语言。
Policy 和 PolicySet 非常相似。在 XACML 中建模时,您可以吸收它们。
您的策略可以包含其他策略 XOR 规则,但不能同时包含两者
编辑
在 OP 的编辑之后,这里有更多的上下文。
XACML 结构元素
XACML 引入了 3 个结构元素:
- 政策集(PS)
- 政策 (P)
- 规则 (R)
正如 OP 所述,PolicySet 可以包含 Policy 和 PolicySet,从而允许整个树的深度与作者希望的一样深(PS --> PS --> PS ... --> P --> R).
策略集、策略和规则的内容
所有三个元素(PS、P、R)可以包含:
- 目标元素:目标是定义元素范围的东西。目标由 AND/OR/AND 结构和属性匹配组成,例如
role=='manager' OR role=='editor'
. - 义务和建议:义务和建议是 return 与从 PDP(策略决策点)返回 PEP(策略执行点)的决定一起编辑的声明
组合算法
因为 PolicySet 和 Policy 元素可以包含子元素,所以它们需要一种机制来解决子元素之间的冲突。该机制称为组合算法。因此,PolicySet 元素和 Policy 元素都有一个组合算法 属性。由于 PolicySet 包含其他 PolicySet and/or 个策略元素,因此 PolicySet 中的组合算法称为 策略组合算法 。由于策略元素只包含规则,所以组合算法称为规则组合算法。
XACML 的另一个怪癖是策略的组合算法列表几乎与规则相同。显着差异是:
- only-one-applicable 仅适用于策略。
- on-permit-apply-second 仅适用于策略。
这是 ALFA notation (ALFA is a pseudo-language developed by Axiomatics 中用于简化 XACML 策略编写的列表):
namespace System {
ruleCombinator denyOverrides = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides"
ruleCombinator permitOverrides = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-overrides"
ruleCombinator firstApplicable = "urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable"
ruleCombinator orderedDenyOverrides = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-deny-overrides"
ruleCombinator orderedPermitOverrides = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:ordered-permit-overrides"
ruleCombinator denyUnlessPermit = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-unless-permit"
ruleCombinator permitUnlessDeny = "urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:permit-unless-deny"
policyCombinator denyOverrides = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-overrides"
policyCombinator permitOverrides = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-overrides"
policyCombinator firstApplicable = "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:first-applicable"
policyCombinator onlyOneApplicable = "urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:only-one-applicable"
policyCombinator orderedDenyOverrides = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-deny-overrides"
policyCombinator orderedPermitOverrides = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:ordered-permit-overrides"
policyCombinator denyUnlessPermit = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:deny-unless-permit"
policyCombinator permitUnlessDeny = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:permit-unless-deny"
policyCombinator onPermitApplySecond = "urn:oasis:names:tc:xacml:3.0:policy-combining-algorithm:on-permit-apply-second"
}
目标和条件
目标
如前所述,Target 元素可以存在于 PolicySet、Policy 和 Rule 中的任何一个中。目标具有 AND/OR/AND 元素的集合结构,用于将属性匹配组合在一起,即给定属性与给定值的比较。 XACML 提供了一长串可以使用的函数。
在目标中,只能使用具有 2 个原子值的函数,并且 return 可以使用布尔值,例如==(或 urn:oasis:names:tc:xacml:1.0:function:string-equal)。其他功能,例如sum (urn:oasis:names:tc:xacml:1.0:function:integer-add) 不能使用。
条件
特别是,有一件非常有用 目标元素不能做的事情:比较两个属性,即建立关系。想象一下,例如你想写一个声明的政策:
Doctors can view the medical record of a patient they are assigned to.
或者换句话说,Permit if userId == assignedDoctorId
。
这是 Condition 元素发挥作用的地方。Condition 是一个表达式,可以使用 XACML 中可用的任何函数。条件的总体结果必须是布尔值,但现在您可以执行 sum(age, limit)>5
或 userId == assignedDoctorId
.
还有一个怪癖:条件元素只能在规则元素内使用。因此,如果您想在 XACML 中表达一种关系,您将需要至少有一个规则。并且由于 Rule 元素不能独立存在。您必须至少有一项政策要素。
所以最小可能的 XACML 策略是(使用 ALFA):
namespace example{
policy policyExample{
apply denyOverrides
rule allowAll{
permit
}
}
}
生成的 XACML XML 代码为:
<?xml version="1.0" encoding="UTF-8"?>
<!--This file was generated by the ALFA Plugin for Eclipse from Axiomatics AB (http://www.axiomatics.com).
Any modification to this file will be lost upon recompilation of the source ALFA file-->
<xacml3:Policy xmlns:xacml3="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
PolicyId="http://axiomatics.com/alfa/identifier/example.policyExample"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:deny-overrides"
Version="1.0">
<xacml3:Description />
<xacml3:PolicyDefaults>
<xacml3:XPathVersion>http://www.w3.org/TR/1999/REC-xpath-19991116</xacml3:XPathVersion>
</xacml3:PolicyDefaults>
<xacml3:Target />
<xacml3:Rule
Effect="Permit"
RuleId="http://axiomatics.com/alfa/identifier/example.policyExample.allowAll">
<xacml3:Description />
<xacml3:Target />
</xacml3:Rule>
</xacml3:Policy>