asp.net webapi动态授权

时间:2014-04-22 17:51:55

标签: c# asp.net-mvc dynamic asp.net-web-api2

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

例如,Tom是UserID 10,Jerry是UserID 20。

任何管理员,呼叫中心或Tom都可以访问

/ api / Account / 10。杰里应该被踢出去。 任何管理员,呼叫中心或杰瑞都应该可以访问/ api / Account / 20。汤姆应该被踢出去。

在webforms中,典型的解决方案是检查用户是否是客户端并根据请求验证其ID。 (我知道AuthorizeAttribute不在webforms中,而是作为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";
    }

这样可行,但似乎所有权检查应该在到达控制器之前在一个位置进行,并且应该可以在整个应用程序中重复使用。我猜最好的地方可能是自定义AuthorizationFilterAttribute或自定义AuthorizeAttribute,也可能创建一个新角色ClientOwner。

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

Custom 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);
    }}

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

这是一种常见的情况,我很惊讶我一直在努力寻找上述情况的例子。这让我相信每个人都在对控制器进行检查,或者还有另一个我不知道的术语,所以我没有得到好的谷歌搜索结果。

1 个答案:

答案 0 :(得分:2)

我认为您可能会将授权权限弄糊涂了。 "动态授权"不是你做过的事情。

授权是验证作者的行为。

  1. 请求声称它是从Alice发送的。
  2. 请求提供密码或授权令牌,证明请求者是Alice。
  3. 服务器验证密码或授权令牌是否与Alice的记录匹配。
  4. 权限是指定谁可以在您的系统中执行操作的业务逻辑。

    1. 请求已获得授权,我们知道它来自Alice。
    2. Alice要求删除重要资源。
    3. Alice是管理员吗?如果没有,告诉她她不能这样做,因为她没有得到许可。 (403禁止)
    4. 内置[Authorize]属性允许您选择指定允许访问资源的Roles。在我看来,将权限指定为授权一部分的选项稍有不妥。

      我的建议是将授权保留为验证请求作者的过程。 BasicAuthHttpModule描述的//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); } 已接近您想要的内容。

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

      {{1}}

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