Attribute-based access control

Last updated

Attribute-based access control (ABAC), also known as policy-based access control for IAM, defines an access control paradigm whereby a subject's authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment attributes. [1]

Contents

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. [2] ABAC policy rules are generated as Boolean functions of the subject's attributes, the object's attributes, and the environment attributes. [3]

Unlike role-based access control (RBAC), which defines roles that carry a specific set of privileges associated with them and to which subjects are assigned, ABAC can express complex rule sets that can evaluate many different attributes. Through defining consistent subject and object attributes into security policies, ABAC eliminates the need for explicit authorizations to individuals’ subjects needed in a non-ABAC access method, reducing the complexity of managing access lists and groups.

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 ]

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). [4]

Dimensions of attribute-based access control

ABAC can be seen as:

Components

Architecture

ABAC comes with a recommended architecture which is as follows:

  1. 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 which it sends to the PDP.
  2. 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
  3. 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:

  1. Subject attributes: attributes that describe the user attempting the access e.g. age, clearance, department, role, job title
  2. Action attributes: attributes that describe the action being attempted e.g. read, delete, view, approve
  3. 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
  4. Contextual (environment) attributes: attributes that deal with time, location or dynamic aspects of the access control scenario [7]

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:

  1. A user can view a document if the document is in the same department as the user
  2. A user can edit a document if they are the owner and if the document is in draft mode
  3. Deny access before 9 AM

With ABAC you can have as many policies as you like that cater to many different scenarios and technologies. [7]

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. [8]

Implementations

There are three main implementations of ABAC:

XACML, the eXtensible Access Control Markup Language, 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 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. [9]

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.

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

The flow would be as follows:

  1. The user, Alice, calls the API method approveTransaction(123)
  2. The API receives the call and authenticates the user.
  3. 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?
  4. The PDP retrieves the ABAC policy and necessary attributes.
  5. The PDP reaches a decision e.g. Permit or Deny and returns it to the API interceptor
  6. If the decision is Permit, the underlying API business logic is called. Otherwise the API returns an error or access denied.

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:

  1. Content Management Systems
  2. ERPs
  3. Home-grown Applications
  4. Web Applications

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

Database security

Security for databases has long been specific to the database vendors: Oracle VPD, IBM FGAC, and Microsoft RLS are all means to achieve fine-grained ABAC-like security.

An example would be:

Data security

Data security typically goes one step further than database security and applies control directly to the data element. This is often referred to as data-centric security. On traditional relational databases, ABAC policies can control access to data at the table, column, field, cell and sub-cell using logical controls with filtering conditions and masking based on attributes. Attributes can be data, user, session or tools based to deliver the greatest level of flexibility in dynamically granting/denying access to a specific data element. On big data, and distributed file systems such as Hadoop, ABAC applied at the data layer control access to folder, sub-folder, file, sub-file and other granular.

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. [10] [11]

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) [12] 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

Related Research Articles

<span class="mw-page-title-main">Access control</span> Selective restriction of access to a place or other resource, allowing only authorized users

In physical security and information security, access control (AC) is the selective restriction of access to a place or other resource, while access management describes the process. The act of accessing may mean consuming, entering, or using. Permission to access a resource is called authorization.

In computer security, an access-control list (ACL) is a list of permissions associated with a system resource. An ACL specifies which users or system processes are granted access to resources, as well as what operations are allowed on given resources. Each entry in a typical ACL specifies a subject and an operation. For instance,

In computer systems security, role-based access control (RBAC) or role-based security is an approach to restricting system access to authorized users, and to implementing mandatory access control (MAC) or discretionary access control (DAC).

Authorization or authorisation is the function of specifying access rights/privileges to resources, which is related to general information security and computer security, and to access control in particular. More formally, "to authorize" is to define an access policy. For example, human resources staff are normally authorized to access employee records and this policy is often formalized as access control rules in a computer system. During operation, the system uses the access control rules to decide whether access requests from (authenticated) consumers shall be approved (granted) or disapproved (rejected). Resources include individual files or an item's data, computer programs, computer devices and functionality provided by computer applications. Examples of consumers are computer users, computer software and other hardware on the computer.

Rule-set-based access control (RSBAC) is an open source access control framework for current Linux kernels, which has been in stable production use since January 2000.

In computer security, mandatory access control (MAC) refers to a type of access control by which the operating system or database constrains the ability of a subject or initiator to access or generally perform some sort of operation on an object or target. In the case of operating systems, a subject is usually a process or thread; objects are constructs such as files, directories, TCP/UDP ports, shared memory segments, IO devices, etc. Subjects and objects each have a set of security attributes. Whenever a subject attempts to access an object, an authorization rule enforced by the operating system kernel examines these security attributes and decides whether the access can take place. Any operation by any subject on any object is tested against the set of authorization rules to determine if the operation is allowed. A database management system, in its access control mechanism, can also apply mandatory access control; in this case, the objects are tables, views, procedures, etc.

In computer security, discretionary access control (DAC) is a type of access control defined by the Trusted Computer System Evaluation Criteria (TCSEC) as a means of restricting access to objects based on the identity of subjects and/or groups to which they belong. The controls are discretionary in the sense that a subject with a certain access permission is capable of passing that permission on to any other subject.

The eXtensible Access Control Markup Language (XACML) is an XML-based standard markup language for specifying access control policies. The standard, published by OASIS, defines a declarative fine-grained, attribute-based access control policy language, an architecture, and a processing model describing how to evaluate access requests according to the rules defined in policies.

The concept of type enforcement (TE), in the field of information technology, is an access control mechanism for regulating access in computer systems. Implementing TE gives priority to mandatory access control (MAC) over discretionary access control (DAC). Access clearance is first given to a subject accessing objects based on rules defined in an attached security context. A security context in a domain is defined by a domain security policy. In the Linux security module (LSM) in SELinux, the security context is an extended attribute. Type enforcement implementation is a prerequisite for MAC, and a first step before multilevel security (MLS) or its replacement multi categories security (MCS). It is a complement of role-based access control (RBAC).

<span class="mw-page-title-main">Organisation-based access control</span> Access control model in computer security

In computer security, organization-based access control (OrBAC) is an access control model first presented in 2003. The current approaches of the access control rest on the three entities to control the access the policy specifies that some subject has the permission to realize some action on some object.

PERMIS is a sophisticated policy-based authorization system that implements an enhanced version of the U.S. National Institute of Standards and Technology (NIST) standard Role-Based Access Control (RBAC) model. PERMIS supports the distributed assignment of both roles and attributes to users by multiple distributed attribute authorities, unlike the NIST model which assumes the centralised assignment of roles to users. PERMIS provides a cryptographically secure privilege management infrastructure (PMI) using public key encryption technologies and X.509 Attribute certificates to maintain users' attributes. PERMIS does not provide any authentication mechanism, but leaves it up to the application to determine what to use. PERMIS's strength comes from its ability to be integrated into virtually any application and any authentication scheme like Shibboleth (Internet2), Kerberos, username/passwords, Grid proxy certificates and Public Key Infrastructure (PKI).

OAuth is an open standard for access delegation, commonly used as a way for internet users to grant websites or applications access to their information on other websites but without giving them the passwords. This mechanism is used by companies such as Amazon, Google, Facebook, Microsoft, and Twitter to permit users to share information about their accounts with third-party applications or websites.

Distributed Access Control System (DACS) is a light-weight single sign-on and attribute-based access control system for web servers and server-based software. DACS is primarily used with Apache web servers to provide enhanced access control for web pages, CGI programs and servlets, and other web-based assets, and to federate Apache servers.

User-Managed Access (UMA) is an OAuth-based access management protocol standard for party-to-party authorization. Version 1.0 of the standard was approved by the Kantara Initiative on March 23, 2015.

In computer security, general access control includes identification, authorization, authentication, access approval, and audit. A more narrow definition of access control would cover only access approval, whereby the system makes a decision to grant or reject an access request from an already authenticated subject, based on what the subject is authorized to access. Authentication and access control are often combined into a single operation, so that access is approved based on successful authentication, or based on an anonymous access token. Authentication methods and tokens include passwords, biometric scans, physical keys, electronic keys and devices, hidden paths, social barriers, and monitoring by humans and automated systems.

The Abbreviated Language for Authorization (ALFA) is a domain-specific language used in the formulation of access-control policies.

Web API security entails authenticating programs or users who are invoking a web API.

<span class="mw-page-title-main">Apache Fortress</span> Open source project of the Apache Software Foundation

Apache Fortress is an open source project of the Apache Software Foundation and a subproject of the Apache Directory. It is an authorization system, written in Java, that provides role-based access control, delegated administration and password policy using an LDAP backend.

The zero trust security model, also known as zero trust architecture (ZTA), and sometimes known as perimeterless security, describes an approach to the strategy, design and implementation of IT systems. The main concept behind the zero trust security model is "never trust, always verify", which means that users and devices should not be trusted by default, even if they are connected to a permissioned network such as a corporate LAN and even if they were previously verified. ZTA is implemented by establishing strong identity verification, validating device compliance prior to granting access, and ensuring least privilege access to only explicitly authorized resources. Most modern corporate networks consist of many interconnected zones, cloud services and infrastructure, connections to remote and mobile environments, and connections to non-conventional IT, such as IoT devices. The reasoning for zero trust is that the traditional approach – trusting users and devices within a notional "corporate perimeter", or users and devices connected via a VPN – is not relevant in the complex environment of a corporate network. The zero trust approach advocates mutual authentication, including checking the identity and integrity of users and devices without respect to location, and providing access to applications and services based on the confidence of user and device identity and device health in combination with user authentication. The zero trust architecture has been proposed for use in specific areas such as supply chains.

In computer systems security, Relationship-based access control (ReBAC) defines an authorization paradigm where a subject's permission to access a resource is defined by the presence of relationships between those subjects and resources.

References

  1. ↑ Computer Security Division, Information Technology Laboratory (2016-05-24). "Attribute Based Access Control | CSRC | CSRC". CSRC | NIST. Retrieved 2021-11-25.
  2. ↑ Hu, Vincent C.; Kuhn, D. Richard; Ferraiolo, David F.; Voas, Jeffrey (February 2015). "Attribute-Based Access Control". Computer. 48 (2): 85–88. doi:10.1109/MC.2015.33. ISSN   1558-0814. S2CID   54967881.
  3. ↑ "Guide to Secure Web Services: Recommendations of the National Institute of Standards and Technology" (PDF).
  4. ↑ Silva, Edelberto Franco; Muchaluat-Saade, Débora Christina; Fernandes, Natalia Castro (2018-01-01). "ACROSS: A generic framework for attribute-based access control with distributed policies for virtual organizations". Future Generation Computer Systems. 78: 1–17. doi:10.1016/j.future.2017.07.049. ISSN   0167-739X.
  5. ↑ "Technology Overview for Externalized Authorization Management". www.gartner.com. Retrieved 2017-05-31.
  6. ↑ "Leadership Compass: Dynamic Authorization Management - 71144". KuppingerCole. Retrieved 2020-07-14.
  7. 1 2 "Alternatives for Roles/Claims Access Control Systems". stackoverflow.com.
  8. ↑ "What Is Attribute-Based Access Control (ABAC)?". www.okta.com. Retrieved 2023-09-13.
  9. ↑ Sanford, Jim. "Encryption on Steroids – Attribute Based Access Control (ABAC)". Siemens. Retrieved 13 October 2023.
  10. ↑ "Dynamic, Fine-Grained Authorization Secures Big Data".
  11. ↑ "First Fine-grained Data Access Control On Hadoop".
  12. ↑ "Dynamic Access Control Overview (Windows 10) - Windows security".
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.