最佳实践:自定义asp.net core身份授权

Fra*_*aze 2 c# claims-based-identity asp.net-identity asp.net-core asp.net-core-2.0

我对 ASP.NET 身份服务器相当陌生。我知道如何自定义 IdentityUser 实体和脚手架/覆盖 Identity UI。鉴于这些情况,我正在寻找有关授权的高级操作方法和最佳实践:

应用程序内的组件需要考虑以下授权事项:

  • 角色
  • 地点
  • 分配
  • 实体(应用程序中的特定组件。如“管理新闻”)

来自网络表单类背景,我倾向于这样思考来定义角色:

public int assignId; //key
public int userId;
public int roleId;
public int? locationId;
public int? divisionId;
public int? entityId;
Run Code Online (Sandbox Code Playgroud)

真实世界场景

  • 具有“全局管理员”角色的用户“Adam”拥有所有权限。
  • 角色“Admin”和位置“Indy”的用户“Joe”拥有“Indy”位置中每个实体的权限。
  • 具有角色“Admin”、位置“Indy”和部门“IT”的用户“Blow”拥有“Indy”中每个“IT”实体的权利
  • 角色“管理员”、位置“芝加哥”、部门“安全”和实体“新闻”的用户“Joe”只能发布芝加哥安全部门的新闻。(除了上述有关乔和印地的规则之外)

那么,我的问题是?

使用 asp.net core 2.1 身份处理此类授权规则/策略的最佳方法是什么?添加“loc”/“indy”等声明?

我会设置自定义授权处理程序来检查声明吗?或者我会像在传统网络表单时代那样设置一个中间件表来处理关联吗?或者这种情况有最佳实践吗?

感谢您的帮助!!!!!!!

itm*_*nus 5

ASP.NET 的早期版本使用基于角色的方法。然而,在这种情况下,首选新的基于声明的方法。因为我们很难确定哪个角色可以访问该资源。

假设您上面描述的三个用户和声明:

  • Adam :角色=全局管理员
  • Joe:角色=管理员;地点=印地&地点=芝加哥;部门=安全;实体=新闻
  • Blow: 行政 ; 地点=印地;部门 = IT ;

AspNetUserClaims表记录了用户的索赔情况如下:

身份证 | 用户ID | 索赔类型 | 索赔价值 |

---|:------|:----------|:----------:|

3 | 3ff3d2db-5a8f-4b01-99b5-fe46d22c240c | 角色 | 全局管理员

4 | cea5d395-fd46-4e6a-aa81-2f4c011b74be | 角色 | 行政

5 | cea5d395-fd46-4e6a-aa81-2f4c011b74be | 地点 | 印地

6 | cea5d395-fd46-4e6a-aa81-2f4c011b74be | 地点 | 芝加哥

8 | cea5d395-fd46-4e6a-aa81-2f4c011b74be | 事业部| 安全

9 | cea5d395-fd46-4e6a-aa81-2f4c011b74be | 实体| 消息

10 | 10 b60c7b75-e31b-4856-ba98-666d013c8201 | 角色 | 行政

11 | 11 b60c7b75-e31b-4856-ba98-666d013c8201 | 地点 | 印地

15 | 15 b60c7b75-e31b-4856-ba98-666d013c8201 | 事业部| 它

正如你所看到的,基于声明的方法的记录相当简单和干净。当需要对用户进行授权时,我们可以将用户的声明与策略进行比较:

services.AddAuthorization(opts=> {
    // ... other policy ...
    // ...
    opts.AddPolicy("Check:Role|Location|Division|Entity", pb=>
        pb.RequireAssertion(async context=> await RldeChecker.Handle(context) )
    );
})
Run Code Online (Sandbox Code Playgroud)

这里的Checker.Handle (context)是一个简单的静态方法,它接收AuthorizationHandlerContex的实例作为参数,并检查用户是否可以访问某些特定资源。

为了更清楚,我们可以添加一个PolicyChecker/文件夹,并将RldeChecker类放入其中:

public class RldeChecker
{
    // ...

    public static async Task<bool> Handle(AuthorizationHandlerContext context) {

        var user = context.User;
        // bypass all checks
        if (user.HasClaim("Role","Global Admin" )) { return true; }
        try
        {
            // retrieve the user claims
            var userLocation = user.FindFirst("Location")?.Value;
            var userDivision = user.FindFirst("Division")?.Value;
            var userEntity = user.FindFirst("Entity")?.Value;
            // retrieve the resource that the user want to access at runtime
            var resource = (Dictionary<string, string>)context.Resource; 
            var targetLocation = resource["Location"];
            var targetDivision = resource["Division"];
            var targetEntity = resource["Entity"];

            // check for local admin
            // ...
        }
        catch {
            return false;
        }
        return false;
    }
}
Run Code Online (Sandbox Code Playgroud)

当我们想要在操作方法中授权用户时,我们可以简单地注入一个实例IAuthorizationService来检查authService.Authorize(user,resource,"Check:Role|Location|Division|Entity")。另外,基于声明的方法允许我们以服务的方式使用它,然后我们可以根据需要将其注入到任何地方,例如根据当前用户的位置/部门/实体显示不同的内容:

var resource = new Dictionary<string, string>() {
    { "Location","Indy"},
    { "Division","IT"},
    { "Entity","News"},
};
var x = await this._authorizationService.AuthorizeAsync(User, resource, "Check:Role|Location|Division|Entity");
if (x.Succeeded)
{
    return View();
}
else
{
    return new ForbidResult();
}
Run Code Online (Sandbox Code Playgroud)