Alternatives for Roles/Claims Access Control Systems

Question

I am developing REST API for the growing system. And in general Role/Claims Access Control work perfecly like this.

[HttpGet]
[Route("settings")]
[Authorization(Type = AuthorizationType.Admin, Permission = Permission.StoreSettings)]
public IHttpActionResult GetSettings() { /*...*/ }

Problem occurs when I have users who can for example control access deeper like in the figure below. This is an abstract example of the system.

And if I need to query something in the one of the area, it is quite simple, but when I need to get all Items from Departments I have to write the same ugly code I can't really reuse. Not real code, but looks like this.

Db.Items.Where(i =>
    i.Stores.Any(s => s.CityId == User.CityId) &&
    Db.UserDepartmentRights.Any(udr => udr.UserId == User.UserId && i.DepartmentId == udr.DepartmentId));

It is obviously ugly and very hard to maintain, especially if I need to bring another level into the system.

Is there any framework which can handle this or at formalized architecture I can implement?

Answer 1

Yes there is. There is a model called ABAC - or attribute-based access control (abac) that does just that.

ABAC Introduction

ABAC is an evolution of RBAC (role-based access control). The claims-based model you use is a form of RBAC where you assign roles and permissions to users. RBAC works well in small, simple deployments but tends to fail when you need to scale up or when you have relationships. In your case, you want to express access control in terms of the relationship between users and stores.

ABAC and RBAC are both models defined by NIST, the National Institute of Science and Technology.

• NIST ABAC
• NIST RBAC

ABAC Constructs

In ABAC, you get 2 types of constructs:

• Attributes. Attributes can be about anything and anyone. They tend to fall into 4 different categories or functions (as in grammatical function)
  • Subject attributes: attributes that describe the user attempting the access e.g. age, clearance, department, role, job title...
  • Action attributes: attributes that describe the action being attempted e.g. read, delete, view, approve...
  • Resource (or object) attributes: attributes that describe the object being accessed e.g. the object type (medical record, bank account...), the department, the classification or sensitivity, the location...
  • Contextual (environment) attributes: attributes that deal with time, location or dynamic aspects of the access control scenario
• Policies are statements that bring together attributes to express what can happen and is not allowed. Policies in ABAC can be granting or denying policies. Examples include:
  • A user can view a document if the document is in the same department as the user
  • A user can edit a document if they are the owner and if the document is in draft mode
  • Deny access before 9am

With ABAC you can have as many policies as you like that cater to many different scenarios.

ABAC Architecture

ABAC comes with a recommended architecture which is as follows:

• The PEP or Policy Enforcement Point is responsible for protecting the apps & data you want to apply ABAC to. In your case, you would likely use an interceptor (e.g. a .NET MessageHandler). The PEP inspects the request and generates an authorization request from it which it sends to the PDP.
• The PDP or Policy Decision Point is the brain of the architecture. This is the piece which evaluates incoming requests against policies it has been configured with. The PDP returns a Permit / Deny decision. The PDP may also use PIPs to retrieve missing metadata
• The PIP or Policy Information Point bridges the PDP to external sources of attributes e.g. LDAP or databases.

ABAC Implementations

The main standard that implements ABAC today is XACML, the eXtensible Access Control Markup Language (xacml). It is a technology-neutral approach to fine-grained access control. There are several implementations of XACML today:

• Vendor
  • Axiomatics Policy Server
  • IBM Tivoli Security Policy Manager
  • Oracle Entitlements Server
• Open Source
  • OpenAZ
  • SunXACML

Learn more

There are a few good resources online you can turn to

• Why lasagna is better than spaghetti: baking authorization into your applications using ALFA, JSON, and REST - Cloud Identity Summit 2014
• Building love and compatibility between RBAC and ABAC