Authorization has been the giant white elephant of AppSec for far too long. Nearly every system today requires it, and organizations spend years of developer time trying to implement, develop, support and enhance authorization built into their code. However, good authorization is needlessly complex. Many organizations start with the basic structure of role-based access control (RBAC), but authorization can and should be much more than that — roles aren’t enough when you have to factor in a constantly growing list of attributes to every possible solution.
These are just some of the questions we have to tackle when designing authorization architecture within our systems:
- How should we model permissions to the system?
- Should we have static roles?
- Should we support an option to define new roles?
- What about groups? Is it easier to assign a user to a group, or assign a role to a user?
- What if we want to restrict access to a specific resource while applying different restrictions to other resources in our system?
The authorization challenge has only grown more complicated as the number of systems, environments, applications and devices for which it’s required continues to increase; For example, creating authorization policy based on belonging to a group in the Active Directory, or based on the status of a ticket in ticketing systems like Jira or ServiceNow. These ever-more complicated parameters of authorization will continue to mutate over time. This means that we can no longer afford to move forward without a radically simpler—and more sustainable—approach to authorization.
Authorization is Hard
Managing even the most basic authorization permissions within an organization has never been easy. In the past, the process of approving access to assets and resources in organizations was carried out by a System Administrator. This was usually completed manually, and required setting or modifying configuration options across several systems. Such processes are highly inefficient, incapable of scaling, needlessly resource-intensive and difficult to maintain.
There have since been many attempts to navigate authorization’s inherent complexities- specifically around permissions. First among them was the short-lived Access Control List (ACL), used to configure groups in Active Directories while simultaneously organizing and managing group members and group permissions. Next came Role-Based Access Control (RBAC), which focused on controlling access based on roles. However, this did not account for the need to set access-based permissions on the assets themselves, and also failed to provide more granular controls. None of the other solutions that have followed since have managed to resolve this problem space either.
Authorization requirements are further complicated by the very structure of modern applications. Most include, or are based on, web interfaces with different authorization requirements across between their front and back ends. Finally, authorization models must always account for the data being accessed (free posts versus paid posts based on the status of the user), and controlling access to the interface itself (for example, a user that is not an Admin should not have the button to view the Users list). This means that our strategies need to plan for all of authorization’s inherent possibilities in order to remain truly flexible, fluid, and scalable.
We Require Authorization Maturity
Over the years, several standards and approaches attempted to address, resolve, and even standardize, best practices to authorization. The eXtensible Access Control Markup Language (known as XACML) was introduced in 2001 as a new standard for authorization. It was quickly adopted- and then dropped- by many companies after being found too cumbersome. After all, it isn’t at all uncommon for standard policies and rules to be incomprehensible and impossible to chance.
XACML’s architectural approach encourages separating Policy Enforcement Points (PEP) and Policy Decision Points (PDP) from both policy management and the code itself. Since XACML is so difficult to manage and write, new and modern policy languages have been created in their stead. These new languages included Sentinel (by HashiCorp), Rego (by OPA) and Polar (by OSO).
As a result, developers must juggle several different authorization languages with their own respective approaches. Some guide you to consume the policy as part of your code; Others encourage you to use an external service (PDP) to actually run the policy. There is no standardization, no true body of dedicated best practices, and certainly no dedicated management consoles.
Everything-as-Code Meets Policy-As-Code
After over a hundred customer calls, we realized that the key to simplified authorization lay in policy. When considering enterprises and compliance, everything should be authorized based on a policy. There should be a policy for maximum machine size allowances that can be run in a cloud environment; as well as a cap on the number of instances a group can run, which ports are allowed to remain open, and which services should have access to what.
It seems that “as-code” is the industry’s latest buzzword, and we’re happily on the bandwagon when it comes to the realm of authorization policy. Developers can hardly be blamed for generating excitement around the idea of writing something “as-code” without having to actually write out any code. And this is exactly what build.security’s platform does—we enable developers to quickly and easily source and write our policies in declarative language, dramatically cutting down the time it takes to build authorization into organizational software.
With build.security, developers can evaluate and generate decisions based on their own customized sets of rules. Decisions can involve a simple “allow” or “deny”, a list of errors in a file following an organizational policy, or a list of permissions a user should have based on their user role and current device.
Try build.security today
build.security’s leveraging the OPA project, a well known, open source project already running in most production environments. Using our SaaS solution you can easily author policies, view and monitor their instances and their decisions, test your policies with new data or against historical data—and still do everything “as-code”, if you want to.
Our platform provides an easy way to author, manage, view, monitor and validate authorization policies across entire applications portfolios. We’re offering developersBuild.security offers organizations the flexibility to decide if the code interests them, or prefer to author policies with a simple (yet powerful) Policy Editor. Writing policies that are data-aware, connecting policies to data sources in runtime, monitoring your environment has never been easier.