+

Stack Overflow: Alternatives for Roles/Claims Access Control Systems

The Axiomatics technical teams across sales engineering, development and customer relations often engage with the Stack Overflow community to get insights and answers. They also contribute knowledge on access control and dynamic authorization.

I am developing REST API for the growing system. And in general Role/Claims Access Control work perfectly 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.

User Types

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?

You can find the rest of the detailed discussion on this topic and guidance from David Brossard here on Stack Overflow.

 

Related Articles

The one with all the authorization vendors | Dynamically Speaking
Dynamically Speaking
Does it feel as though everyone’s suddenly talking about authorization? We think so too and asked Axiomatics President & CCO Jim Barkdoll his thoughts on...
The one about identity-first security | Dynamically Speaking
Dynamically Speaking
Few have their finger on the pulse of all things Identity and Access Management (IAM) like Jackson Shaw, Chief Strategy Officer for Clear Skye. In...
The Log4j vulnerability – What you need to know
Customer Alerts
As many of you know, on December 9, 2021 the Apache Log4j vulnerability (CVE-2021-4422) was discovered, affecting somewhere between 0 and 3 billion-plus devices currently...