Implementing Permissions Control for Related Data Resources

Question

Imagine a data model of an electric company and the city it powers. The company has several departments that manage at least one neighborhood each in the city. The company database includes information for the homes in each neighborhood, the meters installed at homes, billing history, etc... Any employee in a department can login and view all of the different types of data, but they can only view data for the neighborhoods that their department manages. Example schema:

Departments

• ID
• Name

Neighborhoods

• ID
• Name

DepartmentsToNeighborHoods (LinkTable)

• DepartmentID
• NeighborhoodID

Employees

• ID
• Name
• DepartmentID (Foreign Key)

Homes

• ID
• Address
• NeighborhoodID (Foreign Key)

Meters

• ID
• HomeID (Foreign Key)

Given this data model, I'm trying to implement a restful interface where employees can pull data but only on resources within their own department. For example if an employee wants to access the billing history on a particular home, they can only do so if that home is in a neighborhood managed by the employee's department.

The only way I can think of doing this is by implementing a permissions function that checks whether a user can access a particular resource given their user id. A possible implementation (pseudocode):

getMeterDetails(meterID, employeeID) {
    permissionQuery = "
        select 1
        from Meters
            join Homes on Homes.ID = Meters.HomeID
            join Neighborhoods on NeighborHoods.ID = Homes.NeighborHoodID
            join DepartmentsToNeighborhoods as DTN on DTN.NeighborhoodID = Neighborhoods.ID
            join Employees on  Employees.DepartmentID = DTN.DepartmentID
        where Meters.ID = ?
            and Employees.ID = ?
    "

    result = db.runQuery(permissionsQuery, meterID, employeeID)

    if (result == 1) {
        return MeterModel.get(meterID);
    }
    else {
        return ERROR_VALUE;
    }
}

The general issue is that I want to restrict access to particular resources based on membership in another distantly related resource. My current method requires that an additional database query is made each time a resource is requested. I also have to write custom permission queries for each resource I expose because each one uses a different set of relations to determine if the current employee is allowed to access this particular resource. Is there a better method I can use to implement this sort of permission control?

Answer 1

Here is a longer response to your question. The challenge you are hitting is that you have authorization requirements that have multiple parameters / dimensions to them. You want to define permissions that do not simply depend on a user's identity, role, or group, but also based on the data they are getting access to and more importantly the relationship between the users and the data.

The most prevalent authorization framework out there is something called RBAC or role-based access control. RBAC was formalized by NIST, the National Institute of of Standards and Technology. The challenge, in your case, with RBAC, is that it is identity-centric as in it only considers parameters of the user (role, group). You could define a role e.g. manager that would be assigned to a permission e.g. viewMeterData. But that is not enough for you.

To address this, NIST came up with a new model called ABAC (Attribute Based Access Control). In ABAC, you can now use more metadata / parameters. You can for instance consider:

• a user's identity, role, job title, location, department, date of birth...
• a resource's type (meter), location, owner, value, department...
• contextual information e.g. time of day
• the action the user is attempting on the resource

All these are called attributes. Attributes are the foundation of ABAC, hence the name. You can assemble these attributes into policies. Policies are a bit like the secret sauce of ABAC. Policies can grant and deny access. For instance:

• An employee can view a meter if the employee and the meter are in the same region
• Deny access to meter readings between 5pm and 8am.

Policies can be used to express advanced scenarios e.g.

• segregation of duty
• time-based constraints (see above)
• relationship-based access control (see above)
• delegation rules e.g. delegate Bob access to Alice's meter.

There are 2 main syntaxes available to write policies:

• the Abbreviated Language for Authorization (ALFA)
• the eXtensible Access Control Markup Language (XACML)

ABAC also comes with an architecture to define how the policies will get evaluated and enforced.

The architecture contains the following components:

• the Policy Enforcement Point (PEP): this is the component that secures the API / application you want to protect. The PEP intercepts the flow, analyzes it, and send an authorization request to the PDP (see below). It then receives a decision (Permit/Deny) which it enforces.
• the Policy Decision Point (PDP) receives an authorization request (e.g. can Alice view meter #123?) and evaluates it against the set of policies it has been configured with. It eventually reaches a decision which it sends back to the PEP. During the evaluation process, the PDP may need additional metadata e.g. a user's job title. To that effect, it can turn to policy information points (PIP)
• the Policy Information Point (PIP) is the interface between the PDP and underlying data sources e.g. an LDAP, a database, a REST service which contain metadata about users, resources, or other. You can use PIPs to retrieve information the PDP may need at runtime e.g. a risk score, a meter's location, or other.

Implementations

There are several open-source and commercial implementations available. For instance Axiomatics Policy Server (commercial - which is where I work). You will find the entire list online.