基于声明的授权是否适用于单个资源 [英] Is claims based authorization appropriate for individual resources

问题描述

我了解通常用于角色或权限的要求的用法。我知道声明更为笼统，但是从我在实践中看到的情况，通常可以归结为：如果用户拥有这组声明，则可以访问某些区域或执行某些功能。

I understand the usage of claims for things I would commonly refer to as "roles" or "permissions". I know that claims are more general, but from what I have seen in practice, it usually boils down to this: If user has this set of claims they can access certain areas, or perform certain functions.

想象一个Wiki应用程序。您可能有一个允许用户添加内容的 content_contributor 声明，一个允许用户删除内容的 content_admin 声明以及一个 modify_user >可以允许将贡献者权限授予其他用户的声明。

Imagine a wiki application. You might have a content_contributor claim that would allow a user to add content, a content_admin claim that would allow a user to remove content, and a modify_user claim that would allow the granting of contributor rights to other user.

再进一步说明此示例，我可能希望限制用户，以便他们只能看到创建的内容

Taking this example a step farther, I may want to restrict users so that they can only see content created by themselves or their team.

如果用户只能看到他们自己创建的内容，我们是否会对他们创建的每个内容都主张版权，还是我们将其委托给他人？

If a user can only see content created by themselves, would we have a claim for each piece of content they created, or would we delegate that authorization to the application?

推荐答案

当您谈论角色和权限，那么您在谈论的是授权。

When you are talking about roles and permissions then you are talking about authorization.

对于授权，索赔通常不 >。 （Identity）可以对用户的身份进行建模：谁？声明本身并没有说明授权。用户可以声明角色，但这并不能告诉应用程序允许用户做什么。

Claims are typically not for authorization. (Identity)Claims are there to model the identity of the user: who is the user? The claims on itself do not tell anything about authorization. A user can have a role claim, but this doesn't tell the application what the user is allowed to do.

授权由以下人员完成：应用程序，基于用户是谁。将授权视为一组规则，例如：

Authorization is done by the application, based on who the user is. Think of authorization as a set of rules, like:

• 18 + ：允许用户年龄超过18岁（ DateOfBirth ）。

• 18+: allow when user is older than 18 (DateOfBirth).

使用汽车：允许当用户拥有驾驶执照时。

Use car: allow when user has a drivers license.

或者类似的东西。

角色有点混乱，因为它们经常被误用于授权。请阅读本文以获取一些背景信息。

Roles are a bit confusing, as they are often misused for authorization. Please read this article for some background information.

IMO角色的问题是这些角色不是通用的。我可以在一家医院担任医生，而在另一家医院担任患者。对于一个租户，我可以是 Admin ，对于另一个租户，我可以是 User 。因此，它们仅在特定上下文中具有意义。

The problem with roles IMO is that these are not universal. I can be a Doctor in one hospital, while I'm a Patient in another. And I can be Admin for one tenant, but a User for another tenant. So they have only meaning within a certain context.

将角色包含为声明的唯一原因是您无需查找已存在的信息。但是，鉴于前面的评论，您实际上无法包含此信息。而且只会在您这样做时让您头痛。由于您无法执行更新或更改权限或配置文件设置之类的简单操作，因此，除非用户再次登录。

The only reason to include roles as claim is that you won't need to lookup this information as it is already present. But given the previous remark, you actually can't include this information. And it will only give you headaches when you do. Because you can't do simple things like update or change permissions or profile settings, until the user logs in again.

因此，根据经验，应保持授权接近资源（API /网站）。因为那是执行业务规则的地方。这就是可以存储和更新权限等的地方。

So as a rule of thumb: keep authorization close to the resource (api / website). Because that is the place where the business rules are implemented. And that's the place where you can store and update permissions, etc.

在身份验证和授权时，请分开关注。身份验证告诉您用户是谁，授权告诉您允许用户做什么。请勿将两者混用。

Keep a seperation of concerns when it comes to authentication and authorization. Authentication tells you who the user is, and authorization tells you what the user is allowed to do. Don't mix these two.

将其转换为Wiki应用程序：

Translating this to your wiki application:

创建一个单独的上下文，在其中存储角色和权限之类的授权信息。您可以在中央资源中（对于多个应用程序）进行管理，也可以在应用程序中使用上下文。我不会将此上下文与业务上下文混合使用。

Create a seperate context where you store authorization information like roles and permissions. You can manage this in a central resource (for multiple applications) or use the context in your application. I would not mix this context with the business context.

在授权上下文中添加用户并添加角色 content_contributor 。在应用程序内（根据 sub 声明）读取该用户的权限（从中央API，本地授权上下文，设置文件或最合适的任何文件）。将其缓存以提高性能，并应用规则确定是否允许用户访问资源。

Add a user in the authorization context and add a role content_contributor. Within the application read the permissions (from the central API, the local authorization context, a settings file, or anything that suits best) for that user (based on the sub claim). Cache it to speed up performance, and apply the rules to determine whether the user is allowed to access the resource.

您可以使用基于资源的授权。将 sub 声明的值保存在内容记录中以标识所有者。当当前用户与 sub 声明值匹配时，当前用户就是所有者。

You can extend this with resource-based authorization. Save the value of the sub claim in the content record to identify the owner. When the current user matches the sub claim value, then the current user is the owner.

您可以对团队使用相同的方法。将团队表添加到业务环境，并将用户链接到一个或多个团队。在业务上下文中，直接将 sub 索赔值直接使用 sub 索赔值，或使用Users表间接使用Users表。如果您想显示此信息（例如在报告中），可以添加姓名等。

You can use the same approach for teams. Add a teams table to the business context and link the user to one or more teams. Directly using the sub claim value or indirectly, using a Users table, also in the business context, where the user is linked to the sub claim value. You can add name, etc. in case you want to show this information (like in a report).

您可以保存团队ID 和/或用户ID 或 sub 声明值（所有者与当前用户是同一团队的成员），以便确定允许的用户访问权限。

You can save team id and / or user id or sub claim value (owner is member of the same team as current user) in the content record in order to determine the allowed access for the user.

我的设置如下：

身份上下文：用户+用户声明。仅用于身份验证。

Identity context: users + userclaims. For authentication only. Application independent.

授权上下文：用户（id =子声明）+每个应用程序：角色，权限等。在单独的本地数据库或中央数据库中。

Authorization context: users (id = sub claim) + per application: roles, permissions, etc. In seperate 'local' databases or in a central database. For authorization only.

业务环境：用户（Id，名称，外键子声明，没有实际的数据库关系作为表）在上下文之外）+团队，配置文件，设置等。省略了用户表时，链接到 sub 声明值。

Business context: users (Id, Name, 'foreign key' sub claim, without the actual database relation as the table is outside the context) + teams, profile, settings, etc. Linked to the sub claim value when users table is omitted.

按顺序为了使业务上下文中的users表保持最新，请定期刷新值。例如，您可以在x时间后用户登录时更新值。或不时查询身份上下文（使用API​​）以请求用户信息（使用身份用户信息端点）。

In order to keep the users table in the business context up-to-date, periodically refresh the values. You can for instance update values when the user logs in after x time. Or once in a while query the Identity Context (using the API) to request user information (using the identities User Info endpoint).

在所有上下文中都可以包含 users 表，但是它们都有不同的含义并包含其他信息。因此，没有多余的信息。

In all contexts there can be a users table, but they all have a different meaning and contain other information. So there is no redundant information.

授权在应用程序内部进行，并且基于业务规则（策略）和来自授权上下文的授权信息。

Authorization takes place inside the application and is based on the business rules (policies) and authorization information from the authorization context.

最后一点，当当前系统要求角色声明时（例如 User.IsInRole（）或 [Authorize（ role）] ），然后您可以（从缓存中）读取每次调用的角色/权限，并将其添加到当前用户的Claims集合中（claims转换）。

As a final remark, when the current system requires role claims (like for User.IsInRole() or [Authorize("role")]) then you can read (from cache) the role / permissions on each call and add these to the claims collection of the current user (claims transformation).

这篇关于基于声明的授权是否适用于单个资源的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！