在ASP.Net核心中应用粒度权限限制 [英] Applying Granular Right restriction in ASP.Net core

问题描述

背景

在ASP.Net核心中应用粒度权限级别限制的最佳方法是什么.我已经设置了身份验证，并且我的应用程序发出了令牌，令牌会在一定时间后过期.

What is the best way to apply granular right level restriction in ASP.Net core. I've have already set up authentication and my application issues tokens that that expire after a certain amount of time.

我的Web应用程序还利用角色和权限，可以将某个角色与一组权限相关联.我播下了权限并限制了对它们的访问权限，因为即使管理员用户也无法更改，创建或删除任何权限(即只读).另一方面，角色是动态的，尽管super-admin和admin是固定的.任何具有超级管理员访问权限的用户都有权创建新角色并为该角色分配权限.

My web app also makes use of roles and rights, where a certain role is can be associated with a set of rights. I've seeded the rights and restricted access to them in that even admin users cannot change, create or deleted any (i.e. read-only). The roles on the other hand are dynamic, though the super-admin and admin are fixed. Any user with a super-admin access role has the power to create new roles and assign rights to that role.

我要执行的操作是基于这些权限来限制对应用程序中所有其他控制器的访问.

我正在考虑使用基于策略的授权，其中每个权利都将与特定策略(即[Authorize(Policy = "delete users")])相关联.然后，我会将用户拥有的所有权利嵌入到我在登录时发出的令牌中.

I am considering using Policy-based authorization where each right will be associated with a specific policy (i.e [Authorize(Policy = "delete users")]). Then I would embed all the rights the user has in the token I issue out on login.

我不愿意以这种方式实现它，因为尽管权利可能是硬编码的，但它们可能会/会随着时间的推移而增加，如果我拥有大量权利，那么嵌入所有的权利可能会有点效率低下将它们放入令牌.

I am reluctant to implementing it this way since, though the rights may be hard coded, they may/will increase in time, if I have a very large number of rights then I may be a bit inefficient to be embedding all of them into the token.

有没有更好的方法来达到这种安全级别?

Is there a better to achieve this level of security???

推荐答案

如果需要，用自己的话说，

If you need, in your own words,

ASP.Net核心中的粒度权限限制

granular right level restriction in ASP.Net core

您需要外部化您的授权，而不是在您的代码中构建授权.挑战在于，现有框架(在.NET，Java等内部)为您提供角色，有时还可以在您的代码中使用声明来确定用户是否应有权访问给定的功能/事务/数据集.

You need to externalize your authorization rather than build it inside your code. The challenge is that existing frameworks (within .NET, Java...) give you roles and at times claims you can use in your code to determine whether a user should have access to a given function / transaction / data set.

但是，这迫使您每次都编写该代码(对于您的情况为C#).而且，当然，如果您的用例发生了变化，则需要重写代码.它还会迫使您在数据库中创建数据模型/信息模型，并在其中创建用户和角色之间的链接，并可能需要一天的权限.然后您最终想知道如何处理代码或信息模型都不允许的职责分离或委派或其他情况.

But that forces you to write that code (in C# in your case) every time. And, of course, if your use cases change, you need to rewrite your code. it also forces you to create an data model / information model in your database where you create links between users and roles and maybe one day permissions. And then you end up wondering how to handle segregation-of-duty or delegation or other scenarios which neither your code nor your information model allow for.

另一种方法是将您的授权外部化到将为您处理授权请求的外部授权管理器/API.这称为ABAC(或基于属性的访问控制； abac ). ABAC给您:

An alternative is to externalize your authorization to an externalized authorization manager / API that will process authorization requests for you. This is called ABAC (or attribute-based access control; abac). ABAC gives you:

• 架构(请参见下文)
• 一种政策语言(xacml 或 alfa )
• 查询授权引擎的手段
  • 通过是/否许可/拒绝请求/响应流，例如爱丽丝可以查看项目#123吗?" 是的，允许"
  • 或通过开放式接口(例如) 爱丽丝可以看什么?" 销售文件"
  • an architecture (see below)
  • a policy language (xacml or alfa)
  • a means to query the authorization engine
    • either via a Yes/No Permit/Deny request/response flow e.g. "Can Alice view item #123?" "Yes, permit"
    • or via an open-ended interface e.g. "What can Alice view?" "documents in sales"

    在ABAC中，您选择以仅关注应用程序核心业务逻辑的方式构建应用程序/API/解决方案.提供医疗记录.

    In ABAC, you choose to build your apps / APIs / solutions in a way that they only focus on the core business logic of the app e.g. serving medical records.

    对于谁可以查看哪些病历，该应用程序本身不会做出任何决定.您可以将决策委托给称为策略决策点(PDP)的外部授权引擎.

    The app itself will not do any decision making as to who can view which medical records. You delegate the decision making to an external authorization engine known as a Policy Decision Point (PDP).

    要委派授权，请使用称为策略执行点(PEP)的拦截器.该拦截器可以位于您的应用程序代码内，或者-更好的是-位于知名接口的前面，以便可以拦截您的事务/数据流.例如，如果您有API，例如/myservice/records，那么您将让PEP坐在API的前面，以拦截流(JSON，XML ...)

    To delegate the authorization, you use an interceptor called a Policy Enforcement Point (PEP). That interceptor can be within your app code or - better yet - sitting in front of well-known interfaces so that it can intercept your transactions / data flows. For instance, if you have an API e.g. /myservice/records then you would have the PEP sit in front of the API intercepting the flow (JSON, XML...)

    PEP向PDP发送请求，例如:

    The PEP sends requests to the PDP e.g.:

    • 爱丽丝可以查看#123医疗记录吗?
    • Bob可以编辑34号医疗记录的SSN字段吗?
    • Carol可以打印#123条记录吗?

    PDP基于使用属性的策略，以允许，拒绝"答复.这将我们带到第二部分:政策.

    The PDP replies with Permit, Deny based on policies that use attributes. And this brings us to the second part: policies.

    在ABAC(和XACML)中，您可以使用可以想到的任意数量的属性来编写任意数量的策略.简而言之，属性是键值对，例如

    In ABAC (and XACML), you can write any number of policies you like that use any number of attributes you can think of. Attributes are, simply put, key-value pairs e.g.

    • role=="manager"(是，角色可以是属性).
    • dateOfBirth = 1901/04/01
    • citizenship = "German"和"Canadian"
    • role=="manager" (yes, role can be an attribute).
    • dateOfBirth = 1901/04/01
    • citizenship = "German" and "Canadian"

    属性可以是关于用户(如上)的资源，动作或什至是上下文信息，例如时间.

    Attributes can be about users (as above) or resources or actions or even contextual information e.g. time.

    • 记录owner，size，classification，department都是资源的属性.
    • record owner, size, classification, department are all attributes of the resource.

    定义了属性后，就可以开始定义策略了.假设用例是控制对医疗记录的访问，则您可能具有授权要求，例如

    Once you've defined your attributes, you can start defining your policies. Assuming the use case is to control access to medical records, you may have authorization requirements e.g.

    • 医生可以查看分配给他们的患者的病历.
    • 其他医务人员可以查看其所在单位患者的病历.
    • 患者可以查看自己的病历
    • 如果患者是另一位患者的法定监护人，则可以查看该患者的病历.
    • 如果B休假并且A在B的代表列表中，那么A医生可以查看另一位B医生的病历.
    • 没有人可以在医院外查看病历.

    如您所见，您可以编写任意数量的策略，而根本不需要触摸应用程序.您所需要做的就是修改策略.

    As you can see, you can write any number of policies and you don't need to touch your apps at all. All you need to do is edit your policies.

    情况会变得更好:此方法并非特定于ASP.NET.您可以对其他语言(Kotlin，Java ...)，图层(API，数据，UI ...)等等使用相同的方法和体系结构.

    It gets better: this approach is not specific to ASP.NET. You can use the same approach and architecture for other languages (Kotlin, Java...), layers (API, data, UI...), and so on.

    HTH， 大卫.

    • ABAC的优点
    • Wikipedia上的ABAC
    • 维基百科上的XACML
    • Benefits of ABAC
    • ABAC on Wikipedia
    • XACML on Wikipedia

    这篇关于在ASP.Net核心中应用粒度权限限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！