ABAC
acronymsecuritycloudgovernance & risk
Stands for: Attribute-Based Access Control (NIST SP 800-162)
Attribute-Based Access Control: authorisation decided per request by evaluating attributes of the subject, the object, the operation and the environment against policy, rather than by looking up a role.
NIST SP 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, by Hu, Ferraiolo and Kuhn of NIST with Schnitzer, Sandlin, Miller and Scarfone, published in January 2014 and last updated on 2 August 2019, defines it in one sentence: "ABAC is a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes." Where a role-based model asks what role the requester holds, an attribute-based policy asks about the requester's department and clearance, the record's classification and owner, the operation, and conditions such as the time, the location and the device, and can express rules such as a clinician may read the records of patients on their own ward during their shift. The price is that the policy, the attribute sources and their freshness become the system: a stale attribute is a wrong decision. In practice it layers on roles rather than replacing them, and the conditions attached to a network session, device posture, time of day, location of the port, are attribute-based decisions whether or not the policy engine uses the acronym.
Attribute-based access control answers the question role-based control cannot: what if the right answer depends on something about this request, right now, and not only on who is asking. NIST's guide to the subject, Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, written by Hu, Ferraiolo and Kuhn of NIST with Schnitzer of Booz Allen Hamilton, Sandlin and Miller of MITRE and Scarfone, published in January 2014 and last updated on 2 August 2019, gives the definition that the field uses: "ABAC is a logical access control methodology where authorization to perform a set of operations is determined by evaluating attributes associated with the subject, object, requested operations, and, in some cases, environment conditions against policy, rules, or relationships that describe the allowable operations for a given set of attributes."
Each word in that sentence is a component. Subject attributes describe the requester: department, job title, clearance, training completed, employment status. Object attributes describe the thing requested: classification, owner, project, the ward a patient is on. The requested operation is read, write, approve, delete. Environment conditions are what is true at the moment of the request: time of day, the network the request arrives from, the posture of the device, whether a second factor was used. The policy is a set of rules over those attributes, and an access decision is the evaluation of the rules for one request. Nothing has to be pre-computed per user, which is the attraction: a rule such as a clinician may read the records of patients on the ward they are assigned to, during their shift, needs no role per ward per shift, only attributes that are kept current.
The cost is that the attributes are now the system. A role-based model fails when roles multiply; an attribute-based model fails when an attribute is stale, missing or sourced from a system nobody owns, because a wrong attribute produces a confident wrong decision at every request. The guide's title, with its word considerations, signals how much of the document is about governance: who is authoritative for each attribute, how it is kept fresh, how policies are written, tested and audited, and how a decision can be explained afterwards. Auditing is harder than with roles, since there is no static list of who may do what to review, only policies and the attribute values that held at the time; logging the attributes used for each decision becomes part of the design.
In practice the two models coexist. Roles carry the bulk of an organisation's entitlements, because most access really does follow the job, and attributes add the conditions: this role, but only from a managed device; this role, but only during business hours; this permission, but only on records the requester owns. Network access control engines have worked this way for years without using the acronym: an 802.1X or MAB session's authorisation is decided from the identity, the device's posture and profile, the location of the port or the SSID and the time, and changed with a RADIUS Change of Authorization when an attribute changes. The RBAC entry describes the model this one refines, and the least privilege entry the principle both exist to serve.
Also known as: attribute-based access control, attribute based access control, policy-based access control, pbac