Blog

7 Attribute-Based Access Control (ABAC) examples

Explore Attribute-Based Access Control examples across various sectors, including corporate data access, healthcare, finance, and more.


You've heard of Attribute-Based Access Control, or ABAC for short. But you may not know how flexible and incredibly precise this access control method can be. 

ABAC leverages a rich array of attributes, such as user roles, locations, and times of access, to dynamically determine who gets to see what and when. This allows for much more nuanced, data-driven policies that adapt to different access needs and risk profiles, providing flexibility far beyond traditional models like RBAC.

In this article, we'll dive into real-world attribute-based access control examples to showcase its role across industries — from enhancing data security within corporate and government settings to ensuring compliance in healthcare and finance. 

Overview of ABAC

ABAC is a flexible and granular method for controlling access to resources and data. It dynamically determines permissions using attributes like user roles, data sensitivity, and environmental conditions, including time and location. This means access is not only based on who you are but also on the context of your request.  

For instance, a user might only be allowed to view sensitive financial reports during office hours from within the office network.

By leveraging such detailed attributes, ABAC provides highly specific access control, tailor-made for an organization’s unique needs. This approach enhances security by restricting access based on real-time contexts and offers the flexibility needed to adapt as access requirements evolve.

ABAC examples

Example 1: Corporate data access

Corporations often deal with sensitive data, such as financial records, personal employee data, or strategic documents. ABAC is used to:

  • Restrict access to critical data based on attributes like department, job role, clearance level, or even specific project assignments. For example, only employees in the finance department might have access to financial documents, and within those, further granularity is applied where only those holding managerial roles can view reports on high-value transactions.
  • Dynamically grant access to project data based on attributes such as the employee's current project assignments, role within the project (e.g., developer, project manager), and even project phase. For example, let's take Alice, an engineer assigned to a top-secret prototype project. The moment her project manager assigns her as the lead engineer in the system, Alice automatically gains access to critical design documents. This access is refined further by allowing her to view sensitive material only during office hours and within secure company premises. As the project transitions from the design to the testing phase, her access rights adapt to include testing protocols and results. Finally, when the project concludes, her access is automatically revoked.
  • Manage access in remote work environments where teams are scattered globally. Whether an employee logs in from her secure home office or a coffee shop in Nairobi, ABAC systems check not just her identity but also her location and the security level of her connection. Only when all boxes are ticked — identity, location, security — does it grant her access to the network.

Example 2: Healthcare records management

ABAC ensures that only authorized personnel can view or modify patient records based on assigned attributes.

For example, under ABAC:

  • A nurse can access patient records only when those patients are under their direct care, only on their assigned floor, and strictly during their working hours. 
  • In emergencies, ER doctors and nurses automatically gain broader access to patient records to provide immediate care. This access is time-bound and monitored closely through audit logs.
  • Researchers may be granted access to anonymized data only after their research projects receive ethics approval.
  • Pharmacists can access prescription histories only when dispensing medications and only after the prescriptions have been verified by the prescribing doctors.

As patient status changes or staff roles shift, ABAC policies can dynamically adjust access privileges in real time. A doctor reviewing test results can temporarily gain edit rights for a patient’s records just long enough to update the plan, after which their access reverts to viewing only.

Example 3: Financial transactions system

Financial institutions handle a staggering volume of sensitive data and transactions daily and have to comply with strict regulations such as SOX, GDPR, and PCI DSS. With so much sensitive data and money involved, strict access controls are critical.

ABAC allows the creation of extremely granular and dynamic access policies based on attributes like:

  • User role: From tellers to managers, each has defined access limits.
  • Transaction amount: Limits escalate with the size of the transaction.
  • Account type: Different rules for personal, business, or investment accounts.
  • Geographic location and time of day: Adjusting access based on when and where users log in.
  • Risk profiles: Customizing access based on the assessed risk level of transactions and users.

For instance, within ABAC:

  • An investment banker in New York might only have access to accounts managed within their region.
  • Access might only be granted during stock market operating hours or under specific conditions that consider the sensitivity of transactions happening due to market volatility.
  • For large wire transfers or withdrawals, ABAC policies may require that the transaction be approved by two employees: One from the transaction management team and another from the risk management team. Additionally, if the transaction is initiated from a location different from the customer’s usual activity, multi-factor authentication is triggered for an added layer of security.
  • Customer service representatives can access basic account information by default. However, access to more sensitive information, such as credit scores or detailed transaction history, requires customer consent verified through the system, and is only available to representatives who have completed compliance training.

Example 4: Government information systems

ABAC allows for incredibly granular rules to be defined. For example:

  • A policy could state that only users with U.S. citizenship, a certain security clearance level, and a valid need-to-know can access classified intelligence reports originating from allied nations.
  • ABAC policies are configured so that employees can access information from other agencies only if they are part of a joint project team and have the necessary security clearance. 
  • ABAC systems automatically filter access to public records based on the nature of the request and the sensitivity of the data. For example, researchers might be given access to more detailed demographic data under strict privacy conditions, while the general public may access only aggregated or anonymized data.

Example 5: Cloud services management

Here are some examples illustrating how ABAC can be applied in managing access within cloud services:

  • In a multi-tenant environment, cloud service providers often host multiple customers (tenants) within the same infrastructure. ABAC ensures that users can only access data and resources that belong to their own organization. For example, a user from Company A can only access resources tagged with Company A’s tenant ID, and permissions can be further restricted based on the user’s role (e.g., administrator, developer, end-user) within their company.
  •  Different regions have varying laws regarding data residency, requiring data to be stored and processed within specific geographic boundaries. ABAC policies are configured to ensure that data residency complies with local laws. For example, data identified as belonging to European users must be stored and accessed only from servers located within the EU, in compliance with GDPR requirements.
  • ABAC policies allow only authenticated and authorized developers to access certain types of APIs. For example, internal developers might have access to a broader set of APIs than external developers, and certain sensitive API functions (like deleting data) may require additional authorization attributes to be met.
  • ABAC ensures that external applications can access only the data they are permitted to see, based on strict criteria. For instance, a third-party application might only access anonymized data for analytics purposes, provided the data owner has consented to this use.

Example 6: Education and research portals

Universities and research institutions have to manage access to a ton of sensitive data, resources, and applications, from student records to groundbreaking research. 

Here’s how they use ABAC to control access:

  • ABAC rules ensure that only staff with a direct educational or administrative relationship to a student can access sensitive information like grades, disciplinary records, or personal details. For instance, a teacher might only access the records of students currently enrolled in their courses.
  • ABAC policies allow researchers to access data based on their specific roles within a project and the data’s classification. For example, principal researchers might have full access to all project data, while external collaborators might only access data classified as public.
  • ABAC policies ensure that students can access course materials and submit assignments only during the relevant parts of the academic semester and based on their enrollment in the course. Additionally, access to final exams might be restricted to certain dates and times to maintain academic integrity.
  • ABAC ensures that users can only access collaborative tools and materials pertinent to their specific group projects. For instance, a student might have editing rights within their own project group but only viewing rights for other groups' public postings.

Example 7: E-Commerce customer management

With ABAC, you can finely segment your user base by leveraging attributes like:

  • Location
  • Past purchase history
  • Browsing behavior
  • Demographic data
  • Loyalty program status

This allows e-commerce platforms to:

  • Ensure that loyalty program pages and rewards are accessible only to customers who meet specific criteria, such as having spent a certain amount or being a member for a defined period. 
  • Ensure that customer service representatives can access transaction and interaction histories only when handling a customer's inquiry. Access is allowed only if they have the necessary authorization level to view sensitive data.
  • Dynamically adjust security measures based on the risk profile of a transaction. For example, transactions from a region with a high fraud rate or unusually large transaction amounts might require additional verification steps before processing.
  • Enforce that only customers who meet the age requirements and reside in regions where such products are legally sold can view and purchase age-restricted items.

ABAC best practices

To effectively implement ABAC, maintain the following best practices:

  • Define attributes clearly: The first step is clearly defining the attributes that will govern access permissions. User attributes could include role, department, location, etc. Resource attributes cover data classification levels, application contexts, and more.
  • Establish attribute sources: You'll need reliable sources to fetch and validate attribute values in real time. Integrate your ABAC systems with authoritative data sources like HR systems, asset databases, and data classification tools to ensure you have up-to-date attribute values.
  • Create a policy model: The policy model translates business rules into logical conditions using attributes. Policies express who can take what actions on which resources. Make sure your policy model is flexible yet intuitive.
  • Monitor and adjust: Access needs evolve over time. Establish processes to periodically review and refine ABAC policies based on changing requirements and contexts.

The easiest way to implement ABAC

Ready to add ABAC to your app? WorkOS FGA  offers ABAC-like policy support with granular access control and fast authorization checks at scale. With FGA you can express any authorization model including RBAC, ReBAC, ABAC, organization hierarchies, and entitlements with a simple schema language.

With SDKs in every popular language, easy-to-follow documentation, and Slack-based support, you can add ABAC to your app in minutes rather than weeks.

Sign up for WorkOS today, and start selling to enterprise customers tomorrow.

In this article

This site uses cookies to improve your experience. Please accept the use of cookies on this site. You can review our cookie policy here and our privacy policy here. If you choose to refuse, functionality of this site will be limited.