第3章：策略语法与结构——XACML标准与语法归纳总结
好，聊完了ABAC的基础理念和设计思路，我们得落脚到具体的语法上了。你手里有锤子，也得知道怎么抡对吧？说实话，当初我刚接触XACML的时候，第一反应就是：“怎么这么复杂？”一堆PolicySet、Policy、Rule套来套去，看半天说不清它在表达什么。后来用熟了才发现，这种分层结构其实很巧妙。
这一章，我们就来拆解XACML策略语言的标准语法结构。别怕，我会结合项目里踩过的坑，帮你把骨头啃透。
3.1 XACML策略的骨架：三层嵌套结构
XACML的策略树，说白了就是“组织-部门-员工”的关系。顶层是PolicySet（策略集），它底下可以挂多个Policy（策略）或者子PolicySet。每个Policy里放若干个Rule（规则）。
为什么要这么分层呢？我在设计企业级权限系统时，遇到过这样一个场景：公司有全球统一的“数据安全总纲”PolicySet，然后各个业务线（如HR、财务）在自己的PolicySet里写具体的访问规则。如果全部写在同一个平面，维护起来就是灾难。
核心三元素关系：
- PolicySet ：一组逻辑相关的Policy容器，可以嵌套子PolicySet。
- Policy ：针对特定目标的规则集合，包含Target和Rules。
- Rule ：最小的决策单元，包含Target、Condition和Effect。
<!-- 一个简化的XACML三层结构示例 -->
<PolicySet PolicySetId="公司数据策略集"
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:1.0:policy-combining-algorithm:deny-overrides">
<Target><!-- 匹配所有请求 --></Target>
<Policy PolicyId="HR部门策略"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:1.0:rule-combining-algorithm:first-applicable">
<Target>
<Subjects><Subject><SubjectMatch MatchId="...string-equal">
<AttributeValue DataType="...string">HR</AttributeValue>
<SubjectAttributeDesignator AttributeId="department"/>
</SubjectMatch></Subject></Subjects>
</Target>
<Rule RuleId="允许访问员工工资" Effect="Permit">
<Target>
<Resources><Resource><ResourceMatch MatchId="...string-equal">
<AttributeValue DataType="...string">salary_record</AttributeValue>
<ResourceAttributeDesignator AttributeId="resource-type"/>
</ResourceMatch></Resource></Resources>
</Target>
<Condition>
<Apply FunctionId="...time-in-range">
<Apply FunctionId="...current-time"/>
<AttributeValue DataType="...time">09:00:00</AttributeValue>
<AttributeValue DataType="...time">18:00:00</AttributeValue>
</Apply>
</Condition>
</Rule>
</Policy>
</PolicySet>我的小习惯：在XACML的PolicyCombiningAlgId里，我几乎只用“deny-overrides”（拒绝优先）。原因很简单：安全环境里，宁可错杀，不可漏放。RuleCombiningAlgId则常用“first-applicable”，匹配到第一个就停，性能最好。
3.2 核心元素详解：Target、Condition、Effect
一个Rule里，最重要的三个东西就是Target、Condition和Effect。我见过很多新手会把Target和Condition混着用，这是个误区。
Target（目标）
Target是用来做“大筛选”的。它只检查请求的Subject、Resource、Action、Environment等属性是否匹配。它不涉及复杂的逻辑运算，就像一个安检门，只看你的票是不是这趟车。如果Target不匹配，整个Policy或Rule直接跳过，连Evaluate都不会。
Condition（条件）
Condition才是真正“玩逻辑”的地方。你可以在这里嵌套各种函数，做时间比较、集合运算、范围判断。Condition只有在Target匹配后才会被执行。所以，如果你把需要大量计算或函数调用的复杂逻辑放到Target里，你想想看，这会造成多大的浪费？
<!-- 正确的分层使用 -->
<Rule RuleId="仅允许团队经理在工作时间访问" Effect="Permit">
<!-- Target只做属性匹配，不调用函数 -->
<Target>
<Subjects>
<AnyOf>
<AllOf>
<Match MatchId="...string-equal">
<AttributeValue DataType="...string">manager</AttributeValue>
<SubjectAttributeDesignator AttributeId="role"/>
</Match>
</AllOf>
</AnyOf>
</Subjects>
<Resources>
<AnyOf>
<AllOf>
<Match MatchId="...string-equal">
<AttributeValue DataType="...string">team_info</AttributeValue>
<ResourceAttributeDesignator AttributeId="resource-category"/>
</Match>
</AllOf>
</AnyOf>
</Resources>
</Target>
<!-- Condition里放需要计算的逻辑 -->
<Condition>
<Apply FunctionId="...time-in-range">...</Apply>
</Condition>
</Rule>Effect（效果）
就两个值：Permit 和 Deny。没有“Maybe”，没有“Review”。这是XACML明确的地方，决策只有黑白。
| 元素 | 作用域 | 是否支持函数调用 | 执行顺序 |
|---|---|---|---|
| Target | 属性值匹对 | 否（仅Match） | 最先执行 |
| Condition | 布尔逻辑判断 | 是 | Target通过后执行 |
| Effect | 决策结果 | N/A | 最后生效 |
我曾经踩过的坑：在Target里放了time-in-range函数，结果跑下来性能极差。后来查文档才发现，Target设计为轻量级属性匹配，所有复杂函数式调用都应该放到Condition里。嗯，这个教训让我写策略时多了一道检查：先问自己“这能直接匹属性吗？不能就扔Condition里”。
3.3 Combining Algorithm：打架怎么劝？
当多个Policy或Rule同时匹配，最终该听谁的？这就引出了Combining Algorithm。XACML标准定义了几种常用算法：
- deny-overrides：只要有
Deny，结果就是Deny。安全系统首选。 - permit-overrides：有
Permit就行。通常用于宽松的环境，比如内容推荐。 - first-applicable：谁先匹配听谁的。性能最优，但需要严格的策略顺序。
- only-one-applicable：必须唯一匹配，否则返回
NotApplicable或Indeterminate。适合互斥的场景。
个人习惯：在最顶层的PolicySet用deny-overrides，在内部的Policy用first-applicable。这样既保证了安全底线，又维持了内部规则的确定性。
3.4 Obligation与Advice：策略的“副作用”
真正让XACML强大的，除了决策，还有决策后的“动作指导”。这就是Obligation（义务）和Advice（建议）。
举个例子：当Policy判定“拒绝访问”时，可以附带一个Obligation：“记录此次审计日志”。这个Obligation，PEP（策略执行点）是必须执行的，否则系统可视为不合法。而Advice则不那么强制，比如“建议用户更新密码”。
<Rule RuleId="拒绝并记录日志" Effect="Deny">
<Target>
<Resources><Resource>
<ResourceMatch MatchId="...regexp-match">
<AttributeValue DataType="...string">^secret_.*</AttributeValue>
<ResourceAttributeDesignator AttributeId="resource-id"/>
</ResourceMatch>
</Resource></Resources>
</Target>
<Obligations>
<Obligation ObligationId="audit-log" FulfillOn="Deny">
<AttributeAssignment>
<Attribute>
<AttributeValue DataType="...string">审计日志ID: 12345</AttributeValue>
</Attribute>
</AttributeAssignment>
</Obligation>
</Obligations>
</Rule> 一个小技巧：在设计Obligation时，尽量使用FulfillOn="Deny"来记录违规行为，用FulfillOn="Permit"来执行事后检查（比如临时授权需要发送通知）。这样可以避免每次Permit都去记录日志，减少PEP的负担。
3.5 整体知识框架
好了，看到这里，我们其实已经把XACML策略的核心骨架都过了一遍。我用一张图总结一下它们之间的关系，这样你脑子里会有个整体画面。
你看这张图，从PolicySet到Policy再到Rule，一层层递进。你想想看，如果一开始设计策略时不画这样的草图，直接上手写XML，很容易把嵌套搞丢层级，或者把Condition写进Target里。我每次设计新策略集时，都会先在纸上画出这个树形结构，确认清楚每个节点的Combining Algorithm，再落笔写代码。
3.6 避坑指南：常见的XACML语法陷阱
最后分享几个我在项目里被绊倒过的点，大家引以为戒：
- Target的重复定义：别在Policy的Target里限制了属性，又在它内部每个Rule的Target里重复做同样的限制。这样既增加了XML体积，又降低了可读性。我建议：公共限制放在Policy的Target里，Rule的Target只放差异化属性。
- Condition结果为“Indeterminate”：如果Condition里引用的属性不存在，或者函数计算出错，不会直接Deny，而是返回Indeterminate。这时Combining Algorithm的行为会变得很微妙。你一定要在PDP端处理这个状态，否则会引发安全漏洞（比如缺口授权）。
- Obligation的执行顺序：Obligation和Advice的
FulfillOn属性要与Effect一致，别写成FulfillOn="Permit"却只放在Effect="Deny"的Rule里，那样Obligation永远不会执行。我曾经在集成时漏了这一点，结果有一次安全审计没记录到，差点酿成大祸。
嗯，策略语法这块，基础框架就是这些了。你看，XACML并没有想象中那么晦涩，它只是把“如果…那么…”这种条件思维，用一套严谨的标准结构包装了起来。掌握了三层的骨架、Target与Condition的分工、Combining Algorithm的选型，你写出的策略语法，基本就能满足90%的企业级ABAC场景了。