Attribute-based access control
Attribute-based access control grants permissions by evaluating characteristics like department, clearance, or location, instead of a single assigned role.
Category
Governance
See all terms
What is attribute-based access control?
Attribute-based access control (ABAC) grants permissions based on attributes: characteristics of the person making the request, the resource they want, and the context around the request. A policy might check a person's department, clearance level, location, or the time of day, and grant or deny access based on how those attributes line up.
This solves a problem roles run into as systems grow more granular. A role can only carry so much nuance before someone needs a new role for every combination of department, project, and clearance level a person might have. ABAC replaces that growing list of roles with policy rules that read attributes directly, covering combinations that would otherwise need a separate role each.
How does ABAC differ from role-based access control (RBAC)?
RBAC grants access based on a role a person holds, a fixed label like "Sales" or "Manager" that carries a predefined set of permissions. ABAC grants access based on the attributes attached to the person, the resource, and the request itself, evaluated against a policy at the moment access is requested. RBAC answers "what role is this person assigned," while ABAC answers "do these attributes satisfy the policy," which makes ABAC more precise but also harder to audit, since access is computed fresh from whatever attributes are in play rather than listed against a named role.
How does attribute-based access control work?
An ABAC system stores attributes on subjects (the person or agent making a request), objects (the resource requested), and the environment (time, location, device). A policy engine pulls the relevant attributes from all three and checks them against a set of rules, returning an allow or deny decision computed at request time rather than looked up from a static list.
Qontext's access controls work through roles, groups, and per-client permissions rather than a full ABAC policy engine: an agent or person reaches only what their assigned access allows, whether reading a file in the context repository directly or connecting through an API key.