基于索赔的授权是否适用于个人资源

Question

我理解对于我通常称为"角色"或"权限"的事物的声明的用法.我知道声明更为通用,但从我在实践中看到的情况来看,它通常归结为:如果用户有这组声明,他们可以访问某些区域或执行某些功能.

想象一下wiki应用程序.你可能有一个content_contributor要求,将允许用户添加的内容,一个content_admin要求,将允许用户删除内容和modify_user要求,将允许参与者权限其他用户发放.

将此示例更进一步,我可能希望限制用户,以便他们只能看到自己或他们的团队创建的内容.

如果用户只能看到他们自己创建的内容,我们是否会对他们创建的每个内容提出索赔,或者我们是否会将该授权委托给该应用程序？

Answer 1

当您谈论角色和权限时,您正在谈论授权.

索赔通常不用于授权.(身份)声明用于模拟用户的身份:谁是用户？声明本身并不能说明授权.用户可以有一定的作用说法,但这并不能告诉应用什么用户被允许做.

授权由应用程序根据用户的身份完成.将授权视为一组规则,例如:

或类似的东西.

角色有点令人困惑,因为它们经常被滥用于授权.请阅读本文以获取一些背景信息.

IMO角色的问题在于它们并不普遍.我可以在一家医院当医生,而在另一家医院我是病人.我可以成为一个租户的管理员,但是另一个租户的用户.所以他们只在某种背景下有意义.

将角色包含为声明的唯一原因是您不需要查找已存在的此信息.但鉴于之前的评论,您实际上无法包含此信息.当你这样做时,它只会让你头疼.因为在用户再次登录之前,您无法执行更新或更改权限或配置文件设置等简单操作.

因此,根据经验:保持授权靠近资源(api /网站).因为这是实施业务规则的地方.这就是您可以存储和更新权限等的地方.

在身份验证和授权方面,请关注一些问题.身份验证会告诉您用户是谁,授权会告诉您允许用户执行的操作.不要混用这两个.

将其翻译为您的wiki应用程序:

创建一个单独的上下文,您可以在其中存储角色和权限等授权信息.您可以在中央资源(针对多个应用程序)中管理它,也可以在应用程序中使用上下文.我不会将此上下文与业务上下文混合在一起.

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

您可以使用基于资源的授权来扩展它.将子声明的值保存在内容记录中以标识所有者.当前用户与子索赔值匹配时,则当前用户是所有者.

您可以对团队使用相同的方法.将团队表添加到业务上下文,并将用户链接到一个或多个团队.直接使用子索赔值或间接使用Users表,也在业务上下文中,用户链接到子索赔值.您可以添加姓名等,以防您想要显示此信息(例如在报告中).

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

我的设置是这样的:

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

授权上下文:用户(id = sub claim)+每个应用程序:角色,权限等.在单独的"本地"数据库或中央数据库中.仅限授权.

业务上下文:用户(Id,名称,'外键'子声明,没有实际数据库关系,因为表在上下文之外)+团队,配置文件,设置等.当省略users表时链接到子声明值.

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

在所有上下文中都可以有一个用户表,但它们都有不同的含义并包含其他信息.所以没有多余的信息.

授权在应用程序内部进行,并基于授权上下文中的业务规则(策略)和授权信息.

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