It is easy to see how the fragmentation of the modern IT landscape caused by the adoption of a Cloud-first model has increased the importance of a having well-managed authorization strategy and the complexity of achieving this goal.
To help you choose the best access control model for your organization or application, we compare the most popular options, we'll also analyze and discuss the various attribute-based and role-based approaches for application authorization, including their applicability, strengths, and weaknesses:
- Role-Based Access Control (RBAC)
- Attribute-Based Access Control (ABAC)
- Policy-Based Access Control (PBAC)
- Hybrid Role and Attribute-Compliant Access
A well-designed authorization system is essential for managing the day-to-day activities to control who has access to what and enable organizations to safely undergo a digital transformation moving more of their business online and into the Cloud.
Understanding the differences between different authorization models is critical for choosing an appropriate access control method for your organization or application.
Role-Based Access Control (RBAC)
Role-Based Access Control (RBAC) is a security and authorization model for securing access to computer
resources used by almost all enterprises to secure their systems. RBAC access is based on roles defined by the business using them. In the RBAC model, roles are created, and then sets of permissions for resources are assigned to the role. Users are then granted one or more roles to receive access to resources.
Fig: RBAC PDP Flow Determining Access to Bob’s X-Ray for Alice
RBAC Benefits
In the RBAC model, since access is not directly assigned to users but bundled into assignments made to roles, the correct assumption is that controlling and maintaining access is easier. Moreover, because roles and access management can be centralized, it is evident who has a role and access to the role grants. There are fewer assignments to be managed, which decreases the cost of security management and compliance auditing. Furthermore, according to a 2010 NIST study, correct RBAC implementation and efficient provisioning can also reduce employee downtime resulting in significant ROI.
- RBAC is deterministic. An RBAC approach makes it easy to know who has access to what at any moment in time.
- RBAC is more direct and easier to visualize. Security admins can visualize the actors and resources they will affect when creating or modifying a policy.
- RBAC is inherently auditable. With RBAC assignments, as the consequences of that access are visible, it is simple for business owners to certify or attest to access granted. This visibility contrasts with ABAC where a “before the fact audit" is impossible and the effects of a rule are difficult to ascertain.
- RBAC can be simpler than ABAC. For example, with RBAC, bundles of access can be directly assigned to a user. To do this in ABAC requires the creation of a new rule.
RBAC Weaknesses
Unfortunately, the precise nature of the RBAC model can also be considered the source of many of its weaknesses:
- RBAC requires advanced knowledge of the Subjects and Resources and, typically, does not support making on-the-fly contextual decisions.
- An RBAC-only approach can result in an enormous number of roles to accomplish fine-grained authorization.
- Resource owners must know something about the roles and their intended purpose to grant access to those roles accurately.
- Resources must be organized into collections to facilitate delegation.
- Probably the most well-known problem with RBAC is “role explosion.” Organizations often end up with large numbers of roles to accommodate people performing the same job function within different geographical or functional areas within the company. Given a substantial number of roles and collections of resources, a correspondingly large number of delegations would need to be created and managed.
ATTRIBUTE-BASED ACCESS CONTROL (ABAC)
Attribute-Based Access Control (ABAC): An access control method where the subject requests to perform operations on objects are granted or denied based on assigned attributes of the subject, assigned attributes of the object, environment conditions, and a set of policies that are specified in terms of those attributes and conditions.
The policies that can be implemented in an ABAC model are limited only to the degree imposed by the computational language and the richness of the available attributes.
Essentially, the more decision data at your disposal at runtime, the more sophisticated your ABAC policies can be.
ABAC relies on user attributes for authorization decisions. ABAC policies are rules that evaluate access based upon the following four sets of attributes:
- Subject – the attributes concerning the person or actor being evaluated.
- Resource – the attributes of the target or object being affected.
- Action – describe the action to be performed on the Resource
- Environment – includes attributes such as the time of the day, IP subnet, and others that do not relate to
either the Subject or the Resource.
Fig: NIST SP 800-162 ABAC Definition
ABAC Benefits
The key advantage of ABAC is that it does not allow application developers to hardcode a static list of roles and oversimplify their authorization source code. Rather, ABAC forces them to centralize all authorization decisions and call out at runtime to decide based on the Subject, Resource, Action, and Environment request attributes. Another key benefit is ABAC’s sometimes simpler nature. This simplicity can make it easier to understand how a rule grants access to a resource when dealing with a small number of rules. In contrast, RBAC does seem foreign to many users, and, especially during the early phase of its adoption, the levels of abstraction can be challenging for an IT team.
One other added advantage of ABAC is its flexibility. With ABAC, as long as the necessary data is available, almost anything can be represented as a rule-based query. For example, a rule evaluated at runtime in a login session can use contextual information—even information passed in via SAML claims or JWT tokens. In contrast, when delivering the role membership for a user to the application, a standard RBAC engine would not evaluate this type of information.
Everything we cover in this blog can be explored further in our whitepaper “A Guide to Authorization”. You can find that whitepaper here:
ABAC Primary Benefits
- ABAC enforces centralized management of authorization policies
- ABAC makes it easy to specify access rules as simple queries.
- ABAC rules can be extraordinarily fine-grained and contextual.
- ABAC rules can evaluate attributes of Subjects and Resources that are not inventoried by the authorization system.
- ABAC rules need less maintenance and overhead because they do not require the creation or maintenance of the structure on which an RBAC model depends, e.g., roles and resource locations.
ABAC Weaknesses
The first challenge we encounter with implementing policies like this is the information needs to be obtained and evaluated at runtime. In our policy example, if we needed to know if the user’s nationality was Swiss, then this information would likely reside in either the corporate Active Directory or HR system. Moreover, if we needed to know if the company was in Emergency Mode or not, this essential information might be difficult to obtain in a live corporate environment. Likewise, if we needed to as certain their out-of-office status, this would reside in a corporate email system such as Microsoft 365. Furthermore, to attain information for network login sessions or the MFA status would require a query to an Identity Provider such as Ping Federate.
ABAC’s Primary Weaknesses
- ABAC makes it extremely difficult to perform a “before the fact audit” and determine the permissions available to a specific user. To successfully determine access, not only might a considerable number of rules need to be executed, but they must also be done in the same order in which the system applies them. As a result, this could make it impossible to assess risk exposure for any given employee position.
- In a comparable manner to how a “Role Explosion” can occur with RBAC, an explosion can also occur with ABAC where a system with N number of attributes would have 2N possible rule combinations.
- Unless rules are kept extremely simple and do not access data from various source systems, ABAC systems with complex rules from multiple attribute sources can be unacceptably slow to answer authorization queries.
RBAC Versus ABAC: Tradeoffs and Balance
As shown in Figure 28, the decision between ABAC and RBAC is a trade-off. On the one hand, you can have fast, simple, and other RBAC related benefits and, on the other, you can have extensible, scalable, and other ABAC-related advantages. To date, the challenge has been to find the right balance for your own organization’s needs. This is where Policy-Based Access Control (PBAC) helps.
POLICY-BASED ACCESS CONTROL (PBAC)
Policy-Based Access Control (PBAC) is not a formally defined standard but rather describes an authorization model that combines RBAC and ABAC concepts and eliminates some of their shortcomings. The key concept behind PBAC is that policies are expressed as assignment relationships that can be visualized and manipulated graphically. Access rights to perform operations against resources or objects are acquired through relationships referred to as associations. This includes the ability to define complex hierarchical relationships with inheritance, which is overly cumbersome in ABAC. One might consider PBAC as “relational ABAC.” PBAC is best used for real time enforcement of authorization decisions where a well-developed role model can be leveraged for policy assignment.
PBAC policies are inherently more efficient than ABAC policies because authorization decisions are not based on multiple computed and then combined local decisions. Instead, they are based on the net result of multiple policies based on relationships existing within a single database. This aspect also allows PBAC to enforce dynamic Segregation of Duties (SOD) rules, which are not entirely achievable with ABAC. A last key feature mentioned is PBAC support for “before the fact audit,” which is the ability to see who has access to a resource at any time, and not just during the real-time evaluation of a policy set.
EMPOWERID’S HYBRID ROLE & ATTRIBUTE-COMPLIANT ACCESS APPROACH
Defining and maintaining compliant access for a large organization can be a daunting task. Some types of applications and use cases are better suited to a more structured role-based approach, whereas others require real-time contextual decisions. RBAC, ABAC, and PBAC are three ways of managing authorization policies. Moreover, while both have overlapping qualities, individually, each one cannot cover all the necessary aspects of access control. However, for optimal, dynamic support of an IT organization’s needs, EmpowerID supports RBAC relational modeling. RBAC relational modeling provides the backbone or structure for defining an organization and its overall policies while leveraging the flexibility and real-time contextual nature of ABAC and PBAC to offer the best comprehensive solution.
EmpowerID’s sophisticated role and relationship modeling allow security architects to model the organization and its structure and policies, including segregation of duties policies to prevent undesired combinations of access. As illustrated above, flexible attribute-based ABAC or PBAC policies support the centralized real-time decision point for applications that can call the EmpowerID API for authorization decisions. The ABAC/PBAC engine enhances or modifies the powerful RBAC engine's decisions, allowing their use only when greater flexibility or contextual information such as risk, location, and MFA type is required. By including the pre-calculated access results that the engine derives from complex RBAC policies that account for inheritance and even attribute-based queries, ABAC/PBAC policies are made much more potent. The end-goal of leveraging each approach's best is to deliver what EmpowerID calls “Compliant Access Delivery.”
What is Compliant Access Delivery: Sign up for our Newsletter!
Conclusion
In summary, we learned that no single method covers all use cases and application technologies. The overall goal of Compliant Access Delivery requires using the best of each approach implemented following the principles of Zero Trust and Least Privilege. When executed correctly, this automates access assignments and reduces an organization’s attack surface, making it harder for attackers to find privileged credentials and offers them fewer capabilities to perform malicious activities when they compromise a privileged account.
The problem is that all of that identity information that you need to synchronize with Active Directory is in different places. The old days of writing a script to copy department code from your HRIS is gone; between network complexity and the cloud, you need a more powerful flexible identity synchronization solution.
The real trick is what you allow them to update via self service. Most shops allow some limited Active Directory self service. But there is so much more that you can open up with a well designed self service identity management system...as long as you put controls, approvals and lifecycle into effect.
Active Directory is a bear to manage through ADUC. It is clumsy and all-encompassing and the ability to manage granulary is exceptionally complex. Delegating and instituting fine grained permissions requires deep and arcane knowledge of Active Directory. In short, Active Directory management is difficult with ADUC and it doesn't have to be that way.
