Attribute-based access control: Difference between revisions

Revision as of 16:25, 19 February 2022

Revision as of 13:56, 7 March 2022

Line 1:

'''Attribute-based accessAccess controlControl''' ('''ABAC'''), also known as P'''policyolicy-based accessAccess controlControl''' for [[Identity management|IAM]], defines an access control paradigm whereby access rights are granted to users through the use of policies which combine attributes together.<ref>{{Cite web|last=Computer Security Division|first=Information Technology Laboratory|date=2016-05-24|title=Attribute Based Access Control {{!}} CSRC {{!}} CSRC|url=https://csrc.nist.gov/Projects/Attribute-Based-Access-Control|access-date=2021-11-25|website=CSRC {{!}} NIST|language=EN-US}}</ref> The policies can use any type of attributes (user attributes, resource attributes, object, environment attributes etc.). This model supports Boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource, and the action. For example: IF the requester is a manager, THEN allow read/write access to sensitive data. The NIST framework introduces the main concepts of ABAC as its entities, i.e. PAP (Policy Administration Point), PEP (Policy Enforcement Point), PDP (Policy Decision Point) and PIP (Policy Information Point).<ref>{{Cite web|last=NIST|first=ABAC|date=2014|title=Guide to Attribute Based Access Control (ABAC) Definition and Considerations|url=https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-162.pdf|url-status=live|archive-url=https://web.archive.org/web/20140207071219/http://nvlpubs.nist.gov:80/nistpubs/specialpublications/NIST.sp.800-162.pdf |archive-date=2014-02-07 |access-date=|website=}}</ref><ref>{{Cite web|last=NIST|date=2016|title=A Comparison of Attribute Based Access Control (ABAC) Standards for Data ServiceApplications|url=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-178.pdf|url-status=live|archive-url=https://web.archive.org/web/20161019230109/http://nvlpubs.nist.gov:80/nistpubs/SpecialPublications/NIST.SP.800-178.pdf |archive-date=2016-10-19 |access-date=|website=}}</ref>

This model supports Boolean logic, in which rules contain "IF, THEN" statements about who is making the request, the resource, and the action. For example, IF the requester is a manager, THEN allow read/ write access to sensitive data.

Unlike role-based access control (RBAC), which employs pre-defined roles that carry a specific set of privileges associated with them and to which subjects are assigned, the key difference with ABAC is the concept of policies that express a complex Boolean rule set that can evaluate many different attributes. Attribute values can be set-valued or atomic-valued. Set-valued attributes contain more than one atomic value. Examples are ''role'' and ''project''. Atomic-valued attributes contain only one atomic value. Examples are clearance and sensitivity. Attributes can be compared to static values or to one another, thus enabling relation-based access control.

The NIST framework introduces the main concepts of ABAC as its entities, i.e. Policy Administration Point (PAP), Policy Enforcement Point (PEP), Policy Decision Point (PDP) and Policy Information Point (PIP).<ref>{{Cite web|last=NIST|first=ABAC|date=2014|title=Guide to Attribute Based Access Control (ABAC) Definition and Considerations|url=https://nvlpubs.nist.gov/nistpubs/specialpublications/NIST.SP.800-162.pdf|url-status=live|archive-url=https://web.archive.org/web/20140207071219/http://nvlpubs.nist.gov:80/nistpubs/specialpublications/NIST.sp.800-162.pdf |archive-date=2014-02-07 |access-date=|website=}}</ref><ref>{{Cite web|last=NIST|date=2016|title=A Comparison of Attribute Based Access Control (ABAC) Standards for Data ServiceApplications|url=https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-178.pdf|url-status=live|archive-url=https://web.archive.org/web/20161019230109/http://nvlpubs.nist.gov:80/nistpubs/SpecialPublications/NIST.SP.800-178.pdf |archive-date=2016-10-19 |access-date=|website=}}</ref>

Unlike role-based access control (RBAC), which employs pre-definedpredefined roles that carry a specific set of privileges associated with them and to which subjects are assigned, the key difference with ABAC is the concept of policies that express a complex Boolean rule set that can evaluate many different attributes. Attribute values can be set-valued or atomic-valued. Set-valued attributes contain more than one atomic value. Examples are ''role'' and ''project''. Atomic-valued attributes contain only one atomic value. Examples are clearance and sensitivity. Attributes can be compared to static values or to one another, thus enabling relation-based access control.

Examples are ''role'' and ''project''.

Atomic-valued attributes contain only one atomic value. Examples are clearance and sensitivity. Attributes can be compared to static values or to one another, thus enabling relation-based access control.

Although the concept itself existed for many years, ABAC is considered a "next generation" authorization model because it provides dynamic, context-aware and risk-intelligent access control to resources allowing access control policies that include specific attributes from many different information systems to be defined to resolve an authorization and achieve an efficient regulatory compliance, allowing enterprises flexibility in their implementations based on their existing infrastructures.

Line 26 ⟶ 35:

# Subject attributes: attributes that describe the user attempting the access e.g. age, clearance, department, role, job title...

# Action attributes: attributes that describe the action being attempted e.g. read, delete, view, approve...

# Object attributes: attributes that describe the object (or resource) being accessed e.g. the object type (medical record, bank account...), the department, the classification or sensitivity, the ___location...

# Contextual (environment) attributes: attributes that deal with time, ___location or dynamic aspects of the access control scenario<ref name="stackoverflow.com">{{cite web|url=http://stackoverflow.com/questions/36705901/alternatives-for-roles-claims-access-control-systems|title=Alternatives for Roles/Claims Access Control Systems|website=stackoverflow.com}}</ref>

Line 38 ⟶ 47:

==Other models==

Historically, access control models have included [[mandatory access control]] (MAC), [[discretionary access control]] (DAC), and more recently [[role-based access control]] (RBAC). These access control models are user-centric and do not take into account additional parameters such as resource information, the relationship between the user (the requesting entity) and the resource, and dynamic information e.g. time of the day or user IP.

ABAC tries to address this by defining access control based on attributes which describe the requesting entity (the user), the targeted object or resource, the desired action (view, edit, delete...), and environmental or contextual information. This is why access control is said to be attribute-based.

==Implementations==

Line 50 ⟶ 59:

An important consideration when evaluating ABAC solutions is to understand its potential overhead on performance and its impact on the user experience. It is expected that the more granular the controls, the higher the overhead.

=== API and micro servicesmicroservices security ===

ABAC can be used to apply attribute-based, fine-grained authorization to the API methods or functions. For instance, a banking API may expose an approveTransaction(transId) method. ABAC can be used to secure the call. With ABAC, a policy author can write the following: