Applying Granular Right restriction in ASP.Net core

问题

Background

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.

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.

What I am trying to do is to restrict access to all the other controllers in my application based on these rights.

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???

回答1:

If you need, in your own words,

granular right level restriction in ASP.Net core

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.

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.

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:

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"

The Architecture

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.

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).

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...)

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

Can Alice view medical record #123?
Can Bob edit the SSN field of medical record #34?
Can Carol print record #123?

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

Attributes & Policies

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" (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.

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.

Doctors can view the medical records of patients they are assigned to.
Other medical staff can view medical records of patients in their unit.
A patient can view their own medical record
A patient can view the medical record of another patient if they are the legal guardian for that patient.
A doctor A can view another doctor (B)'s patients' medical records if B is on vacation and A is on B's delegate list.
No one can view a medical record if they are outside the hospital.

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.

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, David.

Applying Granular Right restriction in ASP.Net core

问题

回答1:

The Architecture

Attributes & Policies

Further Reading