Attribute-based access control: Difference between revisions

Revision as of 20:38, 11 March 2022

Latest revision as of 08:50, 25 August 2025

(40 intermediate revisions by 28 users not shown)

Line 1:

{{Short description|Access control paradigm}}

'''Attribute-based access control''' ('''ABAC'''), also known as '''policy-based access control''' for [[Identity management|IAM]], defines an access control paradigm whereby accessa rightssubject's are grantedauthorization to usersperform a set of operations is determined by evaluating attributes associated throughwith the usesubject, ofobject, policiesrequested whichoperations, combineand, attributesin togethersome cases, environment attributes.<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).

ABAC is a method of implementing access control policies that is highly adaptable and can be customized using a wide range of attributes, making it suitable for use in distributed or rapidly changing environments. The only limitations on the policies that can be implemented with ABAC are the capabilities of the computational language and the availability of relevant attributes.<ref>{{Cite journal |last1=Hu |first1=Vincent C. |last2=Kuhn |first2=D. Richard |last3=Ferraiolo |first3=David F. |last4=Voas |first4=Jeffrey |date=February 2015 |title=Attribute-Based Access Control |journal=Computer |volume=48 |issue=2 |pages=85–88 |doi=10.1109/MC.2015.33 |bibcode=2015Compr..48b..85H |s2cid=54967881 |issn=1558-0814}}</ref> ABAC policy rules are generated as Boolean functions of the subject's attributes, the object's attributes, and the environment attributes.<ref>{{Cite web |title=Guide to Secure Web Services: Recommendations of the National Institute of Standards and Technology |url=https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-95.pdf}}</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 predefineddefines 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 thatcan express a complex Boolean rule setsets that can evaluate many different attributes. AttributeThrough valuesdefining canconsistent besubject set-valuedand orobject atomic-valued.attributes into security policies, ABAC eliminates the need for explicit authorizations to individuals’ subjects needed in a Setnon-valuedABAC attributesaccess containmethod, morereducing thanthe onecomplexity atomicof value.managing access lists and groups.

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>

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.{{Citation needed|date=September 2023}}

Unlike role-based access control (RBAC), which employs predefined 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.

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.

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

Attribute-based access control is sometimes referred to as '''policy-based access control''' ('''PBAC''') or '''claims-based access control''' ('''CBAC'''), which is a Microsoft-specific term. The key standards that implement ABAC are [[XACML]] and [[ALFA (XACML)]].<ref>{{Cite journal|last1=Silva|first1=Edelberto Franco|last2=Muchaluat-Saade|first2=Débora Christina|last3=Fernandes|first3=Natalia Castro|date=2018-01-01|title=ACROSS: A generic framework for attribute-based access control with distributed policies for virtual organizations|url=http://www.sciencedirect.com/science/article/pii/S0167739X17316060|journal=Future Generation Computer Systems|language=en|volume=78|pages=1–17|doi=10.1016/j.future.2017.07.049|issn=0167-739X|url-access=subscription}}</ref>

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.

Attribute-based access control is sometimes referred to as '''policy-based access control''' ('''PBAC''') or '''claims-based access control''' ('''CBAC'''), which is a Microsoft-specific term. The key standards that implement ABAC are [[XACML]] and [[ALFA (XACML)]].<ref>{{Cite journal|last1=Silva|first1=Edelberto Franco|last2=Muchaluat-Saade|first2=Débora Christina|last3=Fernandes|first3=Natalia Castro|date=2018-01-01|title=ACROSS: A generic framework for attribute-based access control with distributed policies for virtual organizations|url=http://www.sciencedirect.com/science/article/pii/S0167739X17316060|journal=Future Generation Computer Systems|language=en|volume=78|pages=1–17|doi=10.1016/j.future.2017.07.049|issn=0167-739X}}</ref>

== Dimensions of attribute-based access control ==

ABAC can be seen as:

* Externalized authorization management<ref>{{Cite web|url=https://www.gartner.com/doc/2358815/technology-overview-externalized-authorization-management|title=Technology Overview for Externalized Authorization Management|website=www.gartner.com|access-date=2017-05-31}}</ref>

* Dynamic authorization management<ref>{{Cite web|url=https://plus.kuppingercole.com/article/mc71144/dynamic-authorization-management/|title=Leadership Compass: Dynamic Authorization Management - 71144|website=KuppingerCole|date=14 July 2020 |access-date=2020-07-14}}</ref>

* Policy-based access control

* Fine-grained authorization

== Components ==

=== Architecture ===

ABAC comes with a recommended architecture which is as follows:

# The PEP or Policy Enforcement Point: it is responsible for protecting the apps & data you want to apply ABAC to. The PEP inspects the request and generates an authorization request from it which it sends to the PDP.

# The PDP or Policy Decision Point is the brain of the architecture. This is the piece which evaluates incoming requests against policies it has been configured with. The PDP returns a Permit/ Deny decision. The PDP may also use PIPs to retrieve missing metadata

# The PEP or Policy Enforcement Point: it is responsible for protecting the apps & data you want to apply ABAC to. The PEP inspects the request and generates an authorization request from it which it sends to the PDP.

# The PDP or Policy Decision Point is the brain of the architecture. This is the piece which evaluates incoming requests against policies it has been configured with. The PDP returns a Permit/ Deny decision. The PDP may also use PIPs to retrieve missing metadata

# The PIP or Policy Information Point bridges the PDP to external sources of attributes e.g. LDAP or databases.

=== Attributes ===

Attributes can be about anything and anyone. They tend to fall into 4 different categories:

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

Line 37 ⟶ 33:

# 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>

=== Policies ===

Policies are statements that bring together attributes to express what can happen and is not allowed. Policies in ABAC can be granting or denying policies. Policies can also be local or global and can be written in a way that they override other policies. Examples include:

# A user can view a document if the document is in the same department as the user

# A user can edit a document if they are the owner and if the document is in draft mode

# Deny access before 9 AM

With ABAC you can have asan manyunlimited policiesnumber asof you likepolicies that cater to many different scenarios and technologies.<ref name="stackoverflow.com"/>

== 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.

==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==

There are three main implementations of ABAC:

One standard that implements attribute- and policy-based access control is [[XACML]], the eXtensible Access Control Markup Language. XACML defines an architecture, a policy language, and a request/ response scheme. It does not handle attribute management (user attribute assignment, object attribute assignment, environment attribute assignment) which is left to traditional [[Identity_management|IAM]] tools, databases, and directories.

* [https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=xacml#CURRENT OASIS XACML]

* [[Abbreviated Language for Authorization|Abbreviated Language for Authorization (ALFA)]].

* [[National Institute of Standards and Technology|NIST]]'s [https://www.nist.gov/identity-access-management/policy-machine-and-next-generation-access-control Next-generation Access Control] (NGAC)

One standard that implements attribute- and policy-based access control is [[XACML]], the eXtensible Access Control Markup Language. XACML, defines an architecture (shared with ALFA and NGAC), a policy language, and a request/ response scheme. It does not handle attribute management (user attribute assignment, object attribute assignment, environment attribute assignment) which is left to traditional [[Identity_managementIdentity management|IAM]] tools, databases, and directories.

Companies, including every branch in the United States military, have started using ABAC. At a basic level, ABAC protects data with ‘IF/THEN/AND’ rules rather than assign data to users. The US Department of Commerce has made this a mandatory practice and the adoption is spreading throughout several governmental and military agencies.[https://community.plm.automation.siemens.com/t5/Digital-Transformations/Attribute-Based-Access-Control-ABAC-Encryption-on-Steroids/ba-p/580836]<ref>{{Cite web|url=https://community.plm.automation.siemens.com/t5/Digital-Transformations/Attribute-Based-Access-Control-ABAC-Encryption-on-Steroids/ba-p/580836|title=Attribute Based Access Control (ABAC) – Encryption on Steroids|last=Coffey|first=Alisa|date=2019-03-28|website=Siemens PLM Community|language=en|access-date=2019-04-01}}</ref>

Companies, including every branch in the United States military, have started using ABAC. At a basic level, ABAC protects data with ‘IF'IF/THEN/AND’AND' rules rather than assign data to users. The US Department of Commerce has made this a mandatory practice and the adoption is spreading throughout several governmental and military agencies.[https://community.plm.automation.siemens.com/t5/Digital-Transformations/Attribute-Based-Access-Control-ABAC-Encryption-on-Steroids/ba-p/580836]<ref>{{Citecite web |last1=Sanford |first1=Jim |title=Encryption on Steroids – Attribute Based Access Control (ABAC) |url=https://communityblogs.plm.automationsw.siemens.com/t5/Digitalthought-Transformationsleadership/2019/03/Attribute28/attribute-Basedbased-Accessaccess-Controlcontrol-ABACabac-Encryptionencryption-on-Steroidssteroids/ba-p/580836 |titlewebsite=AttributeSiemens Based Access Control (ABAC) – Encryption on Steroids|last=Coffey|first=Alisa|date=2019-03-28|website=Siemens PLMMarch 2019 Community|language=en|access-date=2019-04-0113 October 2023}}</ref>

==Applications==

The concept of ABAC can be applied at any level of the technology stack and an enterprise infrastructure. For example, ABAC can be used at the firewall, server, application, database, and data layer. The use of attributes bring additional context to evaluate the legitimacy of any request for access and inform the decision to grant or deny access.

== Applications ==

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.

The concept of ABAC can be applied at any level of the technology stack and an enterprise infrastructure. For example, ABAC can be used at the firewall, server, application, database, and data layer. The use of attributes bring additional context to evaluate the legitimacy of any request for access and inform the decision to grant or deny access.

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 microservices 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 {{Code|approveTransaction(transId)}} method. ABAC can be used to secure the call. With ABAC, a policy author can write the following:

* '''Policy''': managers can approve transactions up to their approval limit

* '''Attributes used''': role, action IDidentifier, object type, amount, approval limit.

The flow would be as follows:

# The user, Alice, calls the API method {{Code|approveTransaction(123)}}

# The user, Alice, calls the API method approveTransaction(123)

# The API receives the call and authenticates the user.

# An interceptor in the API calls out to the authorization engine (typically called a Policy Decision Point or PDP) and asks: ''Can Alice approve transaction 123?''

Line 75:

=== Application security ===

One of the key benefits to ABAC is that the authorization policies and attributes can be defined in a technology neutral way. This means policies defined for APIs or databases can be reused in the application space. Common applications that can benefit from ABAC are:

# Content management systems (CMS)

# Enterprise resource planning (ERP) systems

# Content Management Systems

# Home-grown Applicationsapplications

# ERPs

# Web applications

# Home-grown Applications

# Web Applications

The same process and flow as the one described in the API section applies here too.

Line 87 ⟶ 86:

An example would be:

* Policy: managers can view transactions in their region

* Reworked policy in a data-centric way: users with {{code|code=role == manager}} can do the action {{code|code=SELECT}} on {{code|code=table == TRANSACTIONS}} if {{code|code=user.region == transaction.region}}

=== Data security ===

Line 96 ⟶ 94:

=== Big data security ===

Attribute-based access control can also be applied to Big Data systems like Hadoop. Policies similar to those used previously can be applied when retrieving data from data lakes.<ref>{{cite web|url=httphttps://www.prweb.com/releases/2016/10dynamic_fine_grained_authorization_secures_big_data/prweb13771686.htm|title=Dynamic, Fine-Grained Authorization Secures Big Data|publisher=}}</ref><ref>{{Cite web |title=First Fine-grained Data Access Control On Hadoop |url=http://bluetalon.com/bluetalon-unveils-industry-first-fine-grained-data-access-control-on-hadoop-distributed-file-system-hdfs-with-filtering-and-dynamic-data-masking-capabilities/ |titlearchive-url=First Finehttps://web.archive.org/web/20160323174613/http://bluetalon.com/bluetalon-unveils-industry-first-fine-grained-data-access-control-on-hadoop-distributed-file-system-hdfs-with-filtering-and-dynamic-data-masking-capabilities/ Data Access Control On Hadoop|archive-date=2016-03-23}}</ref>

=== File server security ===

As of Windows Server 2012, Microsoft has implemented an ABAC approach to controlling access to files and folders. This is achieved through dynamic access control (DAC)<ref>{{Cite web|url=https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/dynamic-access-control|title = Dynamic Access Control Overview (Windows 10) - Windows security| date=13 February 2024 }}</ref> and Security Descriptor Definition Language (SDDL). SDDL can be seen as an ABAC language as it uses metadata of the user (claims) and of the file/ folder to control access.

== See also ==

{{columns-list|colwidth=30em|

* [[Access control list]]

Line 110 ⟶ 108:

* [[Graph-based access control]] (GBAC)

* [[Lattice-based access control]] (LBAC)

* [[Transaction-based access control]] (TxBAC)

* [[Mandatory access control]] (MAC)

* [[Organisation-based access control]] (OrBAC)

* [[Role-based access control]] (RBAC)

* [[TransactionRelationship-based access control]] (TxBACReBAC)

* [[RSBAC|Rule-set-based access control (RSBAC)]]

* [[Capability-based security]]

* [[Location-based authentication]]

* [[Risk-based authentication]]

* [[Classified information]]

Line 134 ⟶ 131:

== References ==

{{Reflistreflist}}

== External links ==

* [https://www.immuta.com/articles/attribute-based-access-control/ Role-Based Access Control vs. Attribute-Based Access Control — Explained]

* [http://csrc.nist.gov/projects/abac/ ATTRIBUTE BASED ACCESS CONTROL (ABAC) - OVERVIEW]

* [https://link.springer.com/chapter/10.1007%2F978-3-642-31540-4_4 Unified Attribute Based Access Control Model (ABAC) covering DAC, MAC and RBAC]

* [httphttps://profsandhu.com/dissert/Dissertation_Xin_Jin.pdf Attribute Based Access Control Models (ABAC) and Implementation in Cloud Infrastructure as a Service]

* [https://f5.com/about-us/blog/articles/abac-not-rbac-welcome-to-the-iot-world-of-contextual-security ABAC not RBAC: Welcome to the (IoT) World of Contextual Security, 2015, Lori MacVittie]

* [https://plus.kuppingercole.com/article/mc71144/dynamic-authorization-management Market Compass: Dynamic Authorization Management, 2020, Graham Williamson]

[[Category:Access control]]