c# - asp.net webapi动态授权

Question

我是 webapi 和 mvc 的新手，我正在努力寻找基于角色和资源所有权动态处理授权的最佳实践。例如，帐户页面应允许员工管理员、员工调用中心或拥有客户获取、发布、放置或删除帐户信息。因此，管理员和调用中心员工应该能够获取、发布、放置或删除任何用户 ID 的任何请求，但客户端应该只能对他们拥有的资源执行这些操作。

例如 Tom 的用户 ID 为 10，Jerry 的用户 ID 为 20。

/api/Account/10 应该可由任何管理员、调用中心或 Tom 访问。杰瑞应该被踢出去。 /api/Account/20 应该可以被任何管理员、调用中心或 Jerry 访问。汤姆应该被踢出去。

在 Web 表单中，典型的解决方案是仅检查用户是否是客户端并根据请求验证其 ID。 (我知道 AuthorizeAttribute 不在 Web 表单中，但作为一个示例显示了它将在 webapi/mvc 中隐藏的内容。)

    [Authorize(Roles = "Administrator, CallCenter, Client")]
    public string Get(int userID)
    {
        if (Thread.CurrentPrincipal.IsInRole("Client") && Thread.CurrentPrincipal.Identity.userID != userID)
        { 
            //Kick them out of here.
        }
        return "value";
    }

这会起作用，但似乎所有权检查应该在到达 Controller 之前在单个位置进行，并且应该可以在整个应用程序中重用。我猜测最好的地方是自定义 AuthorizationFilterAttribute 或自定义 AuthorizeAttribute，并且可能创建一个新角色 ClientOwner。

    [Authorize(Roles = "Administrator, CallCenter, ClientOwner")]
    public string Get(int userID)
    {
        return "value";
    }

自定义AuthorizeAttribute

    public override void OnAuthorization(System.Web.Http.Controllers.HttpActionContext actionContext)
    {
        //If user is already authenticated don't bother checking the header for credentials
        if (Thread.CurrentPrincipal.Identity.IsAuthenticated) { return; }

        var authHeader = actionContext.Request.Headers.Authorization;

        if (authHeader != null)
        {
            if (authHeader.Scheme.Equals("basic", StringComparison.OrdinalIgnoreCase) &&
                !String.IsNullOrWhiteSpace(authHeader.Parameter))
            {
                var credArray = GetCredentials(authHeader);
                var userName = credArray[0];
                var password = credArray[1];

                //Add Authentication
                if (true)
                {
                    var currentPrincipal = new GenericPrincipal(new GenericIdentity(userName), null);
                    var user = GetUser(userName);

                    foreach (var claim in user.Cliams)
                    {
                        currentPrincipal.Identities.FirstOrDefault().AddClaim(new Claim(ClaimTypes.Role, claim);
                    }
                    //**************Not sure best way to get UserID below from url.***********************
                    if (user.userTypeID = UserTypeID.Client && user.userID == UserID)
                    {
                        currentPrincipal.Identities.FirstOrDefault().AddClaim(new Claim(ClaimTypes.Role, "ClientOwner"));
                    }
                    Thread.CurrentPrincipal = currentPrincipal;
                    return;
                }
            }
        }

        HandleUnauthorizedRequest(actionContext);
    }}

有人能给我指出正确的方向，即处理个人用户授权的最佳位置吗？这是否仍然在 Controller 中完成，或者我应该将其移动到自定义 AuthorizationFilterAttribute 或自定义 AuthorizationAttribute 或是否有其他地方应该处理？如果正确的位置是在自定义属性中，那么获取 userID 的最佳方法是什么？我应该像上面的示例一样创建一个新角色还是应该做一些不同的事情？

这是一个常见的场景，令我感到非常惊讶的是我一直在努力寻找上述场景的示例。这让我相信要么每个人都在 Controller 中进行检查，要么有另一个我不知道的术语，所以我没有得到好的谷歌结果。

Answer 1

我认为您可能对授权和权限感到困惑。 “动态授权”不是您曾经做过的事情。

授权是验证作者的行为。

1. 请求声称它是由 Alice 发送的。
2. 请求会提供密码或授权 token ，证明请求者是 Alice。
3. 服务器验证密码或授权 token 是否与 Alice 的记录相符。

权限是指定谁可以在系统中执行哪些操作的业务逻辑。

1. 请求已获得授权，并且我们知道它来自 Alice。
2. Alice 请求删除重要资源。
3. Alice 是管理员吗？如果没有，请告诉她不能这样做，因为她没有获得许可。 (403 禁止)

内置的[Authorize]属性允许您选择指定允许访问资源的角色。在我看来，将权限指定为授权的一部分的选项有点错误。

我的建议是将授权保留为纯粹验证请求作者的过程。 BasicAuthHttpModule 描述 here已经接近您想要的了。

需要在操作主体内部处理重要的权限逻辑。这是一个例子:

//Some authorization logic:
//  Only let a request enter this action if the author of
//  the request has been verified
[Authorize]
[HttpDelete]
[Route("resource/{id}")]
public IHttpActionResult Delete(Guid id)
{
    var resourceOwner = GetResourceOwner(id);

    //Some permissions logic:
    //  Only allow deletion of the resource if the
    //  user is both an admin and the owner.
    if (!User.IsInRole("admin") || User.Identity.Name != resourceOwner)
    {
        return StatusCode(HttpStatusCode.Forbidden);
    }

    DeleteResource(id);
    return StatusCode(HttpStatusCode.NoContent);
}

在此示例中，很难将权限逻辑作为操作的属性来传达，因为将当前用户与资源所有者进行比较的权限部分只能在您实际获得资源所有者后才能进行评估来自您的后端存储设备的信息。