本系列文之後也会置於个人网站

现在，让我们再一次把视线放到「身份验证」和「存取控制」这些名词身上。
在入门篇的「浅谈身份验证与授权」已经相当程度的解释过各个名词。
不过今天将要更关注在身份验证与存取控制的细节上。

对於一个应用来说，最重要的是它的 业务逻辑 。
除了业务逻辑本身，为完成所需的工作，会需要取得必要之资源。这可能是一份档案，
镜头、麦克风资源等不同种形式。

在 取得资源 过程中，也会有另外一层业务逻辑，也可能本身就是另一只程序服务，对所需取得的资源，进行 存取控制 。

最後，爲了判断是否具有存取该项资源的权限，有可能有必要进行 身份验证或授权 。

现在，我们将业务逻辑作爲应用服务、存取控制作爲存取控制服务、身份验证作爲身份验证/授权服务来看时序图。

在上面例子，「身份验证/授权服务」可能是身份服务器和授权服务器；「存取控制服务」可能是资源服务器。
但也有不少做法是将身份和授权做在一起，资源存取控制直接由应用(业务逻辑)处理。更甚者，身份验证於应用的不同逻辑层的状况也不少见。

细看身份验证与存取控制

接着，来更仔细的看看身份验证与存取控制内部。这两者都可以想象其内部有一个执行器(executor)。
这个执行器可以根据读取的规则清单(rules list)来判断是否通过身份验证或允许存取资源。

这个执行器可能是执行帐号密码检验，规则清单就是每个人的帐号密码。
透过读取规则清单找到身份识别的帐号，比对与规则清单内的密码，以验证身份。

身份验证并不会只有帐号密码这麽一种，所以可能会有多个执行器，每个执行器都有他的规则清单。
除了帐号密码外，身份私钥验证、一次性密码验证都有可能。

除了可替换的验证方式外，可以改成多增加一个政策输入(Policy)。透过不同的政策，读取不同规则清单，然後执行不同策略。

※ Note: 这里的Policy可能与其他像似系统有很大的不同。有可能称之爲执行模型(model)或策略(strategy)。不过姑且先称之爲policy。尽管有时Policy直接代表者多个规则(rules)，更像是规则清单(rules list)。但你可以想象成该清单上还有一段讯息(meta data)，记载者如何理解这些规则。

然後存取控制和身份验证很像。有非常多种存取控制的政策可以选择。更甚者你可以将执行器单独来看，并将执行器嵌入到业务应用之中。还记得稍微点到过的casbin吗？在我看来他是一个非常巧妙的执行器。或许我们可以在翻外来多聊一点。