思考模型：授权与能力

文章背景与核心概要

本文探讨了仅依靠身份验证（Authentication）和授权（Authorization）系统来管理系统用户行为的概念局限性。通过检查一个实际场景——例如限制访客账户接收外部邮件——作者区分了“授权”（当账户主动尝试执行某项操作时进行检查）与“能力”（可以独立于某个操作进行查询的更广泛特征）。将“能力”识别为一个独立模型，有助于系统管理员避免滥用传统的授权结构（如 Unix 组）作为通用的属性标签。

认识到这一点能够帮助架构师和系统管理员厘清边界：当面对无法通过传统的“主动触发并验证”来解决的策略控制时，跳出原有的认证授权框架，建立独立的“能力”查询模型是更为优雅且正确的解法。

身份验证与授权的局限性

The Limitations of Authentication and Authorization

我最近写过关于我们的身份验证与访问控制问题的文章，当时我们被迫将许多实际上属于授权范畴的东西硬塞进我们的身份验证系统中。而我最近还有了一个额外的认识：有时我们想要的东西甚至不属于某个账户被授权做什么（即它的授权），而是关于一个账户的能力（capabilities）。

I recently wrote about our authentication versus authorization problem, where we've been forced to shoehorn a bunch of things that are actually about authorization into our authentication systems. An additional realization is that some of what we might want isn't even about what an account is authorized for (its authorizations), it's about an account's capabilities.

让我们把这个概念具体化。我们最近考虑的事项之一是：我们是否能轻松创建特殊的受限“访客”账户，使其完全无法使用我们的邮件系统。这不仅超越了无法使用 IMAP 系统或通过认证的 SMTP 发送邮件（这属于身份验证或授权范畴），还包括无法接收发往 <user>@<us> 的外部邮件。

Let's make this concrete. One of the things we considered recently was whether we could easily create special limited 'guest' accounts that couldn't use our email system at all. This went beyond not being able to use our IMAP system or send email via authenticated SMTP (which is authentication or authorization) to not being able to receive outside email to <user>@<us>.

这无法自然地被“授权”概念所涵盖，因为当我们的邮件系统为该账户收到一条消息时，该账户并未尝试做任何事情；这里不存在对该账户的身份验证，因此也无法从中推导出任何授权。

This isn't something that can naturally be covered by 'authorization', because the account involved isn't trying to do anything when our email system receives a message for it; there's no authentication for the account and thus no authorization to be derived from it.

划定分界线

Defining the Dividing Line

核心区别： * 授权是在账户主动尝试做某事时进行检查的。 * 能力是指即使在账户没有尝试做某事时，你也可以进行检查的属性。

The Core Distinction: * Authorization is checked at the point where an account is actively trying to do something. * Capabilities are things that you can check even outside of an attempt by the account to do something.

从抽象意义上将事物视为“能力”，意味着你需要某种方式在访问尝试之外查询或检查账户的能力，并且可能需要某种方式来获取具有特定能力（例如“接收外部邮件”）的所有账户列表。

Thinking of things as capabilities (in the abstract) means that you need some way to query or check an account's capabilities outside of an access attempt, and probably some way to get a list of all of the accounts with a given capability (such as 'receive outside email').

然而，这也意味着你不必把关于账户被允许做什么的每一条信息都塞进授权系统中，尤其是不用塞进你特定的授权系统所允许表达的范畴内。

However, it also means you don't have to fit every last piece of information about what an account is allowed to do into an authorization system, or especially into what your particular authorization system allows you to express.

误用授权系统的陷阱

The Pitfall of Misusing Authorization Systems

你可以通过将 Unix 登录名放入 yesmail 或 nomail Unix 组（取决于哪个更常见）来记录它们是否可以接收邮件，但将 Unix 的基本授权系统用于此目的可能并不是一个特别好的主意。

You could record whether or not Unix logins can receive email by putting them in yesmail or nomail Unix groups, depending which is more common, but this is probably not a particularly good use of Unix's basic authorization system.

尤其是当其中并不涉及实际的 Unix 文件系统权限，而这些组仅被用作标记时，这意味着你已经将 /etc/groups 变成了一个用于登录的通用属性标签系统。

Especially if there's no actual Unix filesystem permissions involved and the groups are being used only as markers, so you've turned your /etc/groups into a general attribute tag system for logins.

作为超集的“能力”

Capabilities as a Superset

如果你可以随时查询能力，那么它们很可能也可以用于授权决策。从某种意义上说，能力是授权的超集。

If you can query capabilities at any time, they can probably be used for authorization decisions as well, so in a sense, capabilities are a superset of authorizations.

不过，其底层机制可能会有所不同：某些系统期望在执行身份验证的同时接收（或生成）授权信息，而不是在某人通过身份验证后，再进行单独的查询来确定授权状态。

The mechanics may be different, though, in that some things will expect to receive (or generate) authorization information at the same time as they perform authentication, not to make a separate query to determine authorization status once someone has been authenticated.

结论

Conclusion

对我而言，这是一个极其有用的见解——特别是当你的大部分授权实际上都是根据人们是否能够向某个特定服务进行身份验证来决定的情况（就像我们的情况一样）。

For me, this is an especially useful insight if most of your authorization is actually being decided based on whether or not people can authenticate to some particular service (as is our case).

现在，我拥有了一个更通用的模型来思考： * 一个账户能做什么 * 我们希望记录关于它的什么信息 * 我们如何想要表达某些事物

Now I have a more general model for thinking about: * What an account can do * What we want to record about that * How we want to express some things

此外，现在我划清了一条界限：一边是我们或许可以尝试通过身份验证和授权来表达的事物，另一边则是我们需要跳出该模型才能处理的事物。

Also, now I have a dividing line I can draw between something we can maybe try to express through authentication and authorization and something we need to step outside of that model to handle.

(来源: 原博客文章评论)

(Source: Original Blog Post Comments)