问基于索赔的授权是否适合于个人资源？

EN

当您谈论角色和权限时，您就是在谈论授权。

声明通常是，而不是授权的。(身份)声明是用来建模用户的标识的：是用户吗？关于授权的声明本身并没有透露任何关于授权的信息。用户可以拥有一个角色声明，但这并不能告诉应用程序允许用户做什么。

授权由应用程序根据用户的身份进行。将授权视为一组规则，如：

• 18+：允许当用户超过18岁(DateOfBirth)。
• 使用汽车:允许当用户有驾驶执照。

或者类似的东西。

角色有点混乱，因为它们经常被滥用于授权。请阅读这篇文章获得一些背景信息。

海事组织作用的问题是，这些作用不是普遍性的。我可以是一家医院的医生，而我是另一家医院的病人。我可以是一个租户的管理员，但也可以是另一个租户的用户。因此，它们只有在特定的背景下才有意义。

将角色作为声明包含的唯一原因是您不需要查找此信息，因为它已经存在。但鉴于之前的评论，你实际上不能包括这些信息。只有当你这么做的时候才会让你头疼。因为在用户再次登录之前，您不能做简单的事情，比如更新或更改权限或配置文件设置。

因此，经验法则是:将授权保持在资源附近(api /网站)。因为这就是实现业务规则的地方。这就是您可以存储和更新权限的地方，等等。

当涉及到身份验证和授权时，要保持关注点的分离。身份验证告诉您用户是谁，授权告诉您允许用户做什么。别把这两样混在一起。

将此转换为您的wiki应用程序：

创建单独的上下文，在其中存储授权信息(如角色和权限)。您可以在中央资源中(对于多个应用程序)管理这一点，也可以在应用程序中使用上下文。我不会将此上下文与业务上下文混为一谈。

在授权上下文中添加一个用户，并添加一个角色content_contributor。在应用程序中，读取该用户的权限(来自中央API、本地授权上下文、设置文件或任何最适合该用户的内容)(基于子声明)。缓存它以提高性能，并应用规则来确定是否允许用户访问资源。

您可以用基于资源的授权来扩展它。在内容记录中保存子索赔的值以标识所有者。当当前用户匹配子索赔值时，当前用户就是所有者。

您可以对团队使用相同的方法。将teams表添加到业务上下文中，并将用户链接到一个或多个团队。直接使用子索赔值，或者间接使用user表，也可以在业务上下文中使用，其中用户被链接到子索赔值。您可以添加名称等，以防要显示此信息(如在报表中)。

您可以在内容记录中保存team id和/或user id或(所有者与当前用户是同一团队的成员)，以确定用户允许的访问权限。

我的设置应该是这样的：

身份上下文:用户+用户声明。仅用于身份验证。应用独立。

授权上下文:用户(id = sub )+每个应用程序:角色、权限等，在独立的“本地”数据库或中央数据库中。只作授权。

业务上下文:用户(Id，Name，‘外键’子声明，没有实际的数据库关系，因为表在上下文之外)+团队，配置文件，设置等。当用户表被省略时，链接到子声明值。

为了使业务上下文中的users表保持最新，定期刷新值。例如，当用户在x时间之后登录时，可以更新值。或者偶尔查询身份上下文(使用API)以请求用户信息(使用身份用户信息端点)。

在任何情况下，都可以有一个users表，但它们都有不同的含义，并包含其他信息。所以没有多余的信息。

授权发生在应用程序内部，并且基于来自授权上下文的业务规则(策略)和授权信息。

最后，当当前系统需要角色声明(如User.IsInRole()或[Authorize("role")])时，您可以(从缓存中)读取每个调用的角色/权限，并将它们添加到当前用户的索赔集合(索赔转换)中。