Authorization, What Are My Options?

•
Date Posted: 14 December 2020; •
Author: Andrew Clymer; •
Estimated Reading Time: 10 minute read

Applications are designed to deliver functionality to users - this is their primary goal. However, commonly, not all users can do everything in an application: features may be sensitive, they may need a premium subscription, or someone may need to give the user explicit permission to access their data. Delivering this "limiting" of functionality is also a critical part of application design. This article explores options for controlling access to functionality and assesses their strengths and weaknesses

Applications, APIs, and services often need to restrict actions performed by a subject (typically a user). For example, only doctors can sign death certificates, and only if they are not the primary carer. We can define access control as "Can a subject perform a given action?". Organizations evolve. People move between departments, and whole department responsibilities change. In the face of this, access control must adapt as well. Therefore, any access control system needs to allow administrators to change access control decisions quickly and efficiently.

Change doesn't just come from within an organization. Security regulatory changes may affect the way an application needs to work. How, then, can the organization prove compliance with the new regulations? Efficient auditing by regulatory experts is essential to maintain the delivery of service. Having an automated process to perform auditing leads to greater business confidence in continual compliance.

In Software as a Service (SaaS) environments, applications may use access control for revenue protection. When a customer attempts to access an API or feature they have not subscribed to, the application must deny their request. Ideally, the customer then subscribes, makes their payment, and is immediately granted access. Access control should ideally be aware of the immediate change in a subscription.

Access control is the gatekeeper to keeping personal data safe, ensuring regulatory compliance, and protecting company revenue. All business areas rely on access control in one way or another and so making the rules accessible and verifiable to all stakeholders brings significant benefits.

Access Control Possibilities

Developers have used various techniques over the years to implement access control:

Access Control Lists
Group/Role-Based Access Control (RBAC)
Claims as Permissions
Combinations of application logic and Claims
Attribute-Based Access Control policy (ABAC)

Access Control Lists

Access control lists (ACL) require administrators to assign explicit permissions on each resource. Changing security policy or auditing means visiting lots of resources, and application developers must take care to ensure that all resources, from the moment of creation, have the appropriate protection.

Role-Based Access Control (RBAC)

Role-Based Access Control (RBAC), popular in the 2000s, defines a series of relationships between role membership and permissions. RBAC scales better than ACLs but often leads to role explosion as organizations evolve. For example, a sales role allowing access to customer records worked well initially. As the organization expands and creates geographical sales teams, access to customer records must be restricted geographically, resulting in US-Sales and EMEA-Sales roles. RBAC is a heavily manual process requiring IT Administrators to update a user's set of rights manually, resulting in a high ownership cost. RBAC can work well to solve coarse grain access control. For example, the scenario:

"Users with the management role can approve purchase orders"

What it fails to offer is fine-grain access control, such as:

"A manager can approve purchase orders but only for ones originating from their department"

To solve the second scenario, the application developer would need to write an additional check inside the application code, resulting in access control defined in two places. Having security reside in two places results in:

A high cost of security management
A high cost of compliance and auditing
No single view of security policy

RBAC’s system for managing fine-grained access control is an unsustainable, manual process that does not scale.

Claims as Permissions

Many organizations use some form of claims-based identity solution for access control. Once a user has proved who they are, applications get access to a set of claims associated with the user. These claims could be first name, last name, date of birth and what roles they occupy inside the organization. In effect, these claims are about the user's identity, like a physical passport or company ID card.

Identity claims provide a good starting point for making authorization decisions. For example, all users assigned the role of a manager by the organization can create purchase orders; this resembles an RBAC style solution with the application code mapping roles to permissions. Relying purely on identity claims can work for some coarse grain solutions. However, developers often lean towards using identity claims for delivering fine-grain permissions. Granting fine-grain permissions to users allows virtually infinite possibilities on what a given user can achieve. For example, if we need to grant Sally in the HR department temporary permission to perform Bob's job of raising purchase orders, add the specific permissions to Sally:

{"sub":"1234567890","name":"Sally","role":"manager","department":"personal","canRaiseAPurchaseOrder":"true","maxValueForPurchaseOrder":"1000"}

So, while extremely flexible, the identity claims approach has the following issues:

It is hard to audit and verify that the correct people have the correct permissions for their job function.
Re-organising roles and responsibilities is a manual process.
As an employee’s job function changes in the organization, administrators add permissions, but they rarely take them away.
Decision data (maxValueForPurchaseOrder) is defined in the security system, almost certainly replicated from its “source of truth”, the finance system.
Utilizing OAuth and OpenID SSO results in large access tokens containing the user's full set of permissions.
Identity Claims are exactly that – information about an identity. They should not be permissions.

All the solutions considered so far have the following characteristics:

Static rules
A manual process of managing permissions
Hard and expensive to audit
Expensive to adapt to changes in the organization

Claims with Application Logic

After rejecting using identity claims as permissions, developers often use identity claims to add access control policy into the application code:

{ 
  "sub": "1234567890",
  "name": "John Doe",
  "role": "manager",
  "department": "sales "
}

var maxPo = FindMaxPoValue(department)
If ( role ==‘manager’ && poTotal < maxPo )

This approach has the advantage that the access control logic can fetch data from its originating system. In this example, the finance system would set the purchase order limit. Then, instead of the purchase order limit being delivered as a claim, the access control logic retrieves it from the finance system, the single source of truth. If John moves department, the purchase order limit used will be from his new department. Adding access control logic-driven from identity claims into an application certainly hits a sweet spot:

IT admins manage identity
Decisions are driven from the information source, not a copy entered into the access control system.

What this approach doesn't deliver on is:

Ease of audit: it requires an auditor to read application code
Updating access control logic without application re-deployment
Encouraging clear separation of concerns
Sharing access control logic with all stakeholders

An access control solution that can deliver on the following would be highly desirable:

Driven from information that naturally occurs in the organization
No additional management overhead
Can be changed without redeploying applications
Readable by all stakeholders
Auditable

Attribute-Based Access Control (ABAC)

One such approach is attribute-based access control (ABAC), sometimes called policy-based access control. Rather than assign access rights to users directly, policies grant access rights to subjects by evaluating Boolean rules. For example, below is some pseudo code for a rule to allow door access could be expressed as

If the current time is between 08:00 and 18:00 and the user has role employee

The data used to drive the rules are known as attributes and can originate from anywhere, not just identity claims. For example, attributes could be the current time, or the owner of the resource to which the subject is attempting to gain access.

Unlike all the other approaches listed so far, as requirements change ABAC does not require the manual setting of permissions. Instead, it requires changes to policy logic, which can then immediately affect the access control of all subjects.

ABAC obtains the attributes used to drive policy not from a single security system, but from anywhere in the organization. For example, if an employee moves department, the HR system is updated, and the access control policies immediately pick up any security ramifications due to the move. ABAC has been in existence for many years. NIST has a formal definition for ABAC. The formal definition has the following components:

Policy Enforcement Point (PEP)
Policy Decision Point (PDP)
Policy Access Point (PAP)
Policy Information Point (PIP)

Application code interacts with the PEP when it needs to decide whether to permit or deny a request. The PEP builds context for the request and asks the PDP to make the decision. The PDP fetches the policies from the PAP and evaluates the request against the policies using attributes from the supplied context and obtaining any required additional attributes from the PIP. A PAP solution that can react to changes in the policy store results in an immediate change to security policy without redeploying the applications.

Many ABAC solutions are based on the OASIS XACML architecture . As its name suggests, is rooted in XML. Security professionals define XML policies or use graphical tools to build the XML. This is where OASIS XACML falls down; it does not provide a format consumable by non-security professionals. Pablo Giambiagi designed an alternative to XACML, called ALFA, a domain-specific language for describing OASIS policies. Below is a fragment of ALFA that defines a door access policy:

namespace AcmeCorp.DoorPolicy
{
  import Oasis.Attributes

   policy buildingAccess
   {
     target clause ResourceType == "door"
     apply denyUnlessPermit

     // Employees can open the door during office hours only
     rule openMainDoor
     {
       target clause Resource == "mainDoor" and
                     Action == "open"
       permit
       condition Subject.Role == "employee" and
                 CurrentTime >= "08:00:00":time and
                 CurrentTime < "18:00:00":time
      }
    }
}

ALFA's core goal is that virtually anyone can read and verify the intent. OASIS adopted ALFA in March 2014 as an alternative to XML. Writing security policies in a domain-specific language allows auditors and business stakeholders to contribute and verify security policies against the organization's responsibilities and evolving objectives.

ABAC is growing in popularity in businesses wishing to deliver scalable access control policy, verifiable by all. Our Enforcer component delivers an ABAC solution based on ALFA and the OASIS ABAC policy model ready for you to realize the power of ABAC in your .NET application.