In a previous post, I gave a definition of Authentication. In this post, we’re going to explore authorization, which is typically the next step in the processing pipeline after authentication. The concepts described here can apply equally to traditional web applications, SPA apps, mobile apps, APIs, services, and other systems.
What is Authorization?
After a principal is authenticated by a system, the system must determine whether the principal is allowed to access the resource or perform the action that is being requested. The process of making this determination is called authorization. This process can be simple (such as Role-Based Access Control based upon group membership) or complex based upon a combination of static user attributes and dynamic attributes that are determined at run-time.
There are several concepts in play:
Principal: An authenticated entity that is requesting to perform some action on a resource.
Resource: An application, service, API, or other network accessible endpoint the principal wants to access or perform an action on.
Role: An abstraction of the set of resources and actions on those resources that together are the functionality that is needed to perform some business activity.
Group: A collection of principals (authenticated users).
Action: An activity that can be performed on a resource. Typical examples include execute, read, write, delete, or HTTP verbs.
Authorization Policy: A mapping between roles and groups.
Coarse Grained Authorization vs Fine Grained Authorization
Coarse Grained Authorization (CGA) and Fine Grained Authorization (FGA) are two concepts that are often used in application security. There is no industry standard definition for these terms; so, the details tend to vary from one organization to another.
CGA is the top-level authorization decision that is made at the perimeter of a system. This decision will typically be based upon the requested resource and action being tied to a role, the user being a member of a group, and the role + group being mapped together (or not) as part of an authorization policy. As an example, mapping an API path + HTTP verb to an LDAP group is a very common CGA scenario. CGA decisions are best made as close to the edge of the network as possible in self-contained system (such as a Websphere DataPower appliance, ISAM/TAMeb, or Ping access). Often, CGA decisions are sufficient to satisfy business and application requirements.
In the more complex scenarios, additional details will need to gathered about the request and the user at runtime. FGA, as the name would imply, is an authorization decision that is based upon more granular criteria. Anything that is more complex than the CGA decisions described above is considered an FGA decision. A typical FGA decision is an Attribute Based Access Control (see below) decision using LDAP attributes and application-specific context information.
When working with a new client on a project that involves complex authorization concepts, I try to define these concepts (using what I describe here as a starting point) in terms of what makes sense for the situation.
RBAC vs ABAC
Two common forms of authorization decisions are Role-Based Access Control (RBAC) and Attribute-Based Access Control (ABAC).
RBAC is a method of making an authorization decision based upon users being mapped to a role and those roles then being mapped to a set of permissions. A common example of this is LDAP group membership and JEE WAR file security roles.
ABAC is a method of making an authorization decision based upon user attributes, application attributes, system attributes, or environment attributes. These attributes are assembled into a policy (a set of boolean boolean expressions) that is used to determine the authorization decision. ABAC tends to be very flexible; so it is common to find it in FGA decisions. A common example of this is something along the lines of an application needing to allow managers in a call center to access confidential client information during business hours for a client that has called in and has an active ticket open. This type of complex scenario could be modeled using a standards-based approach with eXtensible Access Control Markup Language (XACML).
RBAC and ABAC can be used at any layer of the application architecture. Though, it is typical to see RBAC at the perimeter and ABAC deeper in the architecture.
Relatively simple applications might have no discernible authorization step. The application may not have an authorization step built into it, but its design likely enforces some type of authorization policy. The application might allow any authenticated user to access the application. Or, the application may allow everyone (unauthenticated users and authenticated users) to perform actions (read most likely) on certain resources. It is common to see roles such as:
Everyone Role: A role containing all users of the system.
All Authenticated Users Role: A role containing all principals (authenticated users) of the system.
Even if your system doesn’t have explicit authorization requirements currently, it is wise to have an authorization step that enforces authorization policy even if that policy is allow everyone or allow all authenticated users.
What about OAuth2? It’s an Authorization Protcol Isn’t It?
OAuth2 is a delegated access or delegated authorization protocol. This is a very different concept from what we are describing here where the authorization decision is for the user to access an application or resource that doesn’t involve third party access to resources. Then, it is easy to update the policy later. This assumes that something like XACML or another policy authoring language and a run-time library that can implement it is used to implement the authorization step.
Standards-Based Authorization — XACML
The only fully-featured authorization standard out there (for describing authorization policy) is XACML. The current spec version is 3.0; it was released in January, 2013. The XACML spec allows for wide variety of simple and complex scenarios including RBAC and ABAC for CGA and FGA decisions. XACML has never been as widely used as SAML2 or some other identity protocols; however, its popularity has been steadily growing since 2010. IBM ended its XACML-based product (Tivoli Security Policy Manager, TSPM) a few years ago. Axiomatics and Balana are both active in the XACML space as of Q4, 2017. I’ve used all three of these in the past three years. In a future blog post, I’m going to do a deep dive on XACML.
We’ve explored the major concepts of authorization in this post. All systems should have a defined authorization step, even if it simply allows all authenticated users.
Image: Do not enter / Cory Doctorow