request · 四元组

授权请求：把一次访问拆成 who / when·where / what / action

先不讨论「准不准」，那是规则冲突时谁说了算的主题。先看输入的形状：无论多复杂的权限系统，每一次访问检查，最终都要先装配一个授权请求——一个固定四个槽位的元组。把它传入判定函数 decide(...)，才谈得上 permit / deny。

1 · 四个槽位装配出的元组

授权不是用户身上挂着的一个静态标签，而是「这一刻、这个人、对这个东西、做这件事」这个具体组合的一次性判定。

图 1-1 · 四元组的装配过程与它序列化后的 JSON 形状。可切换 subject、action、resource 与情境，观察元组与 JSON 同步变化。

注 · 关键的心智切换在于：授权是个函数，这四个槽位是它的参数。who、when/where、what 三页逐个拆解前三个参数，decide 再加上 action，把它们合起来运行判定。

这四个轴不是本系列发明的。主流授权系统全都围绕它构建，只是给它们起了不同的名字。认出这层同构，阅读任何权限框架的文档都会容易很多。

表 2-1 · 四个轴在五套系统里的术语对照。各系统的真实写法见现实世界的同一个函数。
系统	who	action	what	when/where
本系列	subject	action	resource	context
XACML	Subject	Action	Resource	Environment
AWS IAM	Principal	Action	Resource	Condition
OPA / Rego	`input.user`	`input.action`	`input.resource`	`input.*`
Cedar	principal	action	resource	`context`

警示 · when/where 之所以单独成一轴，是因为它既不属于「人」也不属于「物」——几点钟、从哪个 IP、什么设备，这些是请求发生的现场。把它和 who / what 并列，是 ABAC 相比 RBAC 最实质的一步扩展：让授权能纳入时间与环境条件。