Discuss the advantages versus disadvantages of employing Access Control Lists or

Question

Discuss the advantages versus disadvantages of employing Access Control Lists or Role-Based Access Control (RBAC) versus a policy based approach like Attribute-Based Access Control (ABAC), defined in NIST (2014) Special Publication 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations, or Context-Based Access Control discussed in Chapter 6 of the textbook. Under which enterprise situations and environments might one be better approach than the other? Discuss the advantages versus disadvantages of employing Access Control Lists or Role-Based Access Control (RBAC) versus a policy based approach like Attribute-Based Access Control (ABAC), defined in NIST (2014) Special Publication 800-162: Guide to Attribute Based Access Control (ABAC) Definition and Considerations, or Context-Based Access Control discussed in Chapter 6 of the textbook. Under which enterprise situations and environments might one be better approach than the other?

Explanation / Answer

RBAC

Role-Based Access Control model (RBAC) employs pre-defined roles that carry a specific set of privileges associated with them and to which subjects are assigned. For example, a subject assigned the role of Manager will have access to a different set of objects than someone assigned the role of Analyst. In this model, access is implicitly predetermined by the person assigning the roles to each individual and explicitly by theobject owner when determining the privilege associated with eachrole. At the point of an access request, the access control mechanism evaluates the role assigned to the subject requesting access and the set of operations this role is authorized to perform on the object before rendering and enforcing an access decision. Note that a role may be viewed as a subject attribute that is evaluated by the access control mechanism and around which object access policy is generated. As the RBAC specification gained popularity, it made central management of enterprise access controlcapabilities possible and reduced the need for ACLs.

ABAC

ACLs and RBAC are in some ways special cases of ABAC in terms of the attributes used. ACLs work on
the attribute of “identity”. RBAC works on the attribute of “role”. The key difference with ABAC is the
concept of policies that express a complex Boolean rule set that can evaluate many different attributes.
While it is possible to achieve ABAC objectives using ACLs or RBAC, demonstrating AC requirements
compliance is difficult and costly due to the level of abstraction required between the AC requirements
and the ACL or RBAC model. Another problem with ACL or RBAC models is that if the AC requirement
is changed, it may be difficult to identify all the places where the ACL or RBAC implementation needs to
be updated.
One example of an access control framework that is consistent with ABAC is the Extensible Access Control
Markup Language (XACML) [XACML]. The XACML model employs elements such as rules, policies,
rule- and policy-combining algorithms, attributes (subject, (resource) object, action and environment
conditions), obligations, and advice. Its reference architecture includes functions such as Policy Decision
Points (PDPs), Policy Enforcement Points (PEPs), Policy Administration Points (PAPs), and Policy
Information Points (PIPs) to control access. Another example is the Next Generation Access Control
standard .
In general, ABAC avoids the need for capabilities (operation/object pairs) to be directly assigned to
subject requesters or to their roles or groups before the request is made. Instead, when a subject requests
access, the ABAC engine can make an access control decision based on the assigned attributes of the
requester, the assigned attributes of the object, environment conditions, and a set of policies that are
specified in terms of those attributes and conditions. Under this arrangement policies can be created and
managed without direct reference to potentially numerous users and objects, and users and objects can be
provisioned without reference to policy.

RBAC is:

identity-centric i.e. it focuses on the user identity, the user role, and optionally the user group
typically entirely managed by the IAM team
admin-time: roles and permissions are assigned at administration time and live for the duration they are provisioned for.
What's not so good with RBAC?

it is coarse-grained. If you have a role called doctor, then you would give the doctor role a permission to
"view medical record". That would give the doctor the right to view all medical records including their own.
This is what leads to role explosion
it is static. RBAC cannot use contextual information e.g. time, user location, device type...
it ignores resource meta-data e.g. medical record owner.
it is hard to manage and maintain. Very often, administrators will keep adding roles to users but never
remove them. You end up with users that dozens if not hundreds of roles and permissions
it cannot cater to dynamic segregation-of-duty.
it relies on custom code within application layers (API, apps, DB...) to implement finer-grained controls.
Access reviews are painful, error-prone and lengthy
Is ABAC the solution?

ABAC - Attribute-Based Access Control - is the next-generation way of handling authorization.
It is driven by the likes of NIST and OASIS as well as open-source communities (Apache)
and IAM vendors (Oracle, IBM, Axiomatics).

ABAC can be see as authorization that is:

Externalized: Access control is externalized from the business logic
Centralized: Access control policies are maintained centrally
Standardized: Access control policies use XACML, the eXtensible Access Control Markup Language,
the standard defined by OASIS and implemented by most ABAC solutions
Flexible: ABAC can be applied to APIs, databases, and more
Dynamic: Access decisions are made dynamically at runtime
Context-based / Risk-based: ABAC can take time, location, and other contextual attributes into account when reaching decisions.
ABAC provides:

an architecture with the notion of a policy decision point (PDP) and policy enforcement point (PEP)
a policy language (XACML)
a request / response scheme (JSON/XACML)

The main disadvantage of RBAC is what is most often called the 'role explosion': due to the
increasing number of different (real world) roles (sometimes differences are only very minor)
you need an increasing number of (RBAC) roles to properly encapsulate the permissions
(a permission in RBAC is an action/operation on an object/entity). Managing all those
roles can become a complex affair.

Because of the abstraction choices that form the foundation of RBAC, it is also not
very well suited to manage individual rights, but this is typically deemed less of a problem.

The typically proposed alternative is ABAC (Attribute Based Access Control). ABAC has
no roles, hence no role explosion. Yet, with ABAC, you get what people now call an 'attribute
explosion'. The two issues are different in the details, but largely the same on a more abstract level.
(A cynic might point to the market saturation for RBAC solutions and the resulting need for
a 'newer' and 'better' access control solution, but that's another discussion.)

Related Questions

Navigate

• Browse (All)
• Browse D
• Subjects

---

---

Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.