更新 : 2018-11-24
记入一些思考
asp.net core + identity 的权限是这样的
user = 1 个登入账号
role = 1 个角色 (类似于公司里的一个职位)
claim = 令牌 (类似于古代，见令令牌如见皇帝或者将军)
一般上我们会把权限建立在 Page, 操作, 资源上.
这里我只说操作, 操作指的是一个 api 接口, 一个 controller 或是一个 action
identity 给了我们一个 policy 的概念
一个 policy 就是说，一个对令牌的判断.
比如，如果一个 user 访问用于某几个令牌，就表示它可以执行.
所以 controller 和 action 我们就会写很多对令牌的要求.
常见的是问，请问你有没有 "admin" 这个令牌丫 ？
也可以是, 请问你有没有 "可转账" 这个令牌丫 ？
那么，令牌这么多，要怎样管理呢 ？
我们知道一间公司一定会有很多工作，要分工。
通常我们把工作分组成任务 (task).
比如，管理广告，管理 live chat, 管理网页内容。等等
这些都是任务。
然后我们需要把任务交给某些人做，人来人往我们得找到一个固定的依赖，所以就有了职位这个概念。
所以任务最后都分给了某些职位.
在 identity 管理中，如果我们的职位很少，而且任务没有重叠，我们可以把 claim 当做 role 来用。
当职位变得多, 任务又有重叠 (同样任务，但是 2 个职位都可以做). 我们可以把 claim 设计当 task 来用。
如果真的要分到很细的话，我们可以把每个 action 定义为一个 cliam, 然后设计一个 task 的概念
1 个任务需要调用多个 action, 所以一个 task 需要多个 claim
然后 1 个 role 可以拥有多个 task (一个职位可以拥有多个 task 符合管理)
最后一个 user 可以有多个 roles, 或者直接拥有某些 task
要有 task 的概念，需要对 identity 扩展一些些.
另外说说授权。
一般上一个公司都会有一个 HR 部分.
只有 HR 有能力处理 user account.
比如给予权限等等。但是有一点不要混淆。在系统上开来，HR 的权限很大，他可以 disable 一个 CEO 的账号。
但是其实他只是任命执行操作而已。就好像是一个 sales man 可以创建订单，但前提是客户要购买东西。他并不可以自己提客户下单一样。
HR 有可能会因为区域很大，而分出好几个区。
account 应该是属于某个区的，也就是说 2 个 HR 并不可以互相访问对方的人事。
参考 :
https://www.cnblogs.com/RainingNight/p/authorization-in-asp-net-core.html
https://www.cnblogs.com/RainingNight/p/authorize-how-to-work-in-asp-net-core.html
https://www.cnblogs.com/RainingNight/p/dynamic-authorization-in-asp-net-core.html
这 3 篇基本上已经讲完了.
对比 .net 4.x 主要是多了 policy, requirement, authoService
一个 policy 表示多个 requirement
一个 requirement 表示多种断言, 比如有没有 claim, 有没有 role 等等
同一个 requirement 还能有不同的验证逻辑.
policy 还有一个合并与其它 policy 的能力. 非常灵活.