Attribute-based access control: Difference between revisions

Revision as of 13:56, 7 March 2022

Revision as of 14:08, 7 March 2022

Line 1:

'''Attribute-based Access Control''' ('''ABAC'''), also known as P'''olicyPolicy-based Access Control''' 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.

Line 28:

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

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

# 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 9am9 AM

With ABAC you can have as many policies as you like that cater to many different scenarios and technologies.<ref name="stackoverflow.com"/>

Line 50:

==Implementations==

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.

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>

Line 77:

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

# content management systems

# ERPs

# homeHome-grown applicationsApplications

# Web Applications

# web applications

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

Line 101:

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