基于声明的授权是否适用于单个资源

那你说的是 授权 .

索赔通常是 不 对于 授权 用户名称: 谁 是用户吗?索赔本身并没有说明任何关于授权的内容。用户可以拥有角色声明,但这并不能告诉应用程序 什么 允许用户这样做。

授权是由应用程序根据用户的身份进行的。把授权看作 一套规则 ,例如:

• :当用户年龄大于18岁时允许( ).

• :当用户有驾照时允许。

this article 一些背景资料。

IMO的问题是,这些角色并不普遍。我可以成为一个 医生 病人 在另一个地方。我也可以 行政 用户

因此,经验法则是:让授权靠近资源(api/网站)。因为那是实现业务规则的地方。在这里你可以存储和更新权限等。

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

将其转换为wiki应用程序:

创建一个单独的上下文,在其中存储角色和权限等授权信息。您可以在一个中心资源(对于多个应用程序)中管理它,也可以在应用程序中使用上下文。我不会把这种情况和 业务背景 .

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

resource-based authorization . 保存 附属的 附属的

您可以对团队使用相同的方法。添加 团队 业务背景 并将用户链接到一个或多个团队。直接使用 也可以在用户链接到 附属的

你可以保存 和/或 或 声明内容记录中的值(所有者与当前用户是同一团队的成员),以确定用户允许的访问权限。

我的设置如下:

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

授权上下文

业务背景 :users(Id,Name,'foreign key'子声明,没有实际的数据库关系,因为表在上下文之外)+链接到 省略用户表时的声明值。

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

在任何情况下都可能有 用户

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

User.IsInRole() 或 [Authorize("role")]