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?

score 27 · Accepted Answer · answered Apr 19 '16 at 12:26

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.

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

Thanks for the summary! I was looking over ABAC couple of times but was not sure it is exactly what I needed. Printed out NIST ABAC, it is going to be fun reading. And thank you again. — Yaroslav Veremenko, Apr 19 '16 at 14:56
Feel free to tweet to me any questions you have. I live and breathe ABAC :-) — David Brossard, Apr 19 '16 at 15:41
I don't think I can implement actual XACML, but at least I can encapsulate all policies using Entity Framework Interceptors. — Yaroslav Veremenko, Apr 19 '16 at 19:34
Absolutely, that is a great approach : externalize and centralize your logic — David Brossard, Apr 20 '16 at 00:23

score 0 · Answer 2 · answered Apr 22 '16 at 13:30

yes, there is ready to use framework, and it works for all .net and non .net apps, you can check this here, VisualGuard , for which I work, It does all the things what you need very easily where you don't need to write any code, just plug it and you can create your restrictions (permissions) on the fly.

Each permission corresponds to one or several actions that will activate, deactivate or modify the application's functionalities.

With dynamic permissions, these actions are defined and stored in the framework only. At runtime, Visual Guard will dynamically load and apply them. As a result, the application code is completely separated from the security code.

you can check it here

http://www.visual-guard.com/EN/net-powerbuilder-application-security-authentication-permission-access-control-rbac/sso-iam-identity-authorization-entitlement-audit-features.php-source_soforum.html