ABAC to the future: The next generation of access control

Sabrina Barkdoll
Mar 12
4 min read

Originally posted on: https://axiomatics.com/blog/abac-to-the-future-the-next-generation-of-access-control

Access control has traveled from the past where “need-to-know” ruled, to the future of “need-to-share” authorization. Historically, access control was all about building barriers, ensuring that only a select few could reach sensitive data. But companies now want to get more out of their information — making data work harder and smarter.

Authorization has shifted from gatekeeping to empowering the right people to access the right data at the right time. Enter attribute-based access control (ABAC): unlocking the potential of secure data sharing in the future.

What is ABAC?

Think of ABAC as the Flux Capacitor for data access. This logical access control approach assesses attributes of users, data, and environmental factors to decide who can access sensitive information. Instead of static roles, ABAC evaluates multiple dynamic attributes — like roles, location, and time — to ensure only authorized access. It’s no longer just about “who” has access, but about “what”, “where”, “why” and “when” they should.

Understanding XACML: The flux capacitor of ABAC

Just like the flux capacitor powers the DeLorean, the eXtensible Access Control Markup Language (XACML) standard powers ABAC. XACML defines a fine-grained, attribute-based access control language that expresses access policies. It evaluates attributes like subject, action, resource, and environment (a bit like deciding who can and can’t ride shotgun with Doc).

Imagine Marty wants to access Biff’s grades as a form of revenge. The XACML policy language is as expressive as a natural language. For example, consider the following sentence:

Students can view their own confidential document at school.

A sentence like this includes four grammatical building blocks:

a subject
an action
a resource
the environment in which the request is made

Each of these building blocks can be described using attributes:

Term	Definition	Examples
Subject	Who or what is demanding access to an information asset.	Roles, group memberships, the department/company to which the user belongs, management level, certifications or competencies, user ID
Action	Action the subject wants to perform.	Read and write are common values. More complex scenarios, like a bank transfer, may use multiple attributes such as “action type=transfer” and “amount=$500”.
Resource	The information asset or object impacted by the action.	For banking, the resource may be “debit account=<your account number>.” In law firms, a resource could be a document and an attribute could be “case matter = 100.”
Environment	The context in which access is requested.	Current time, location from where access is requested, client type (PC, smartphone, etc.), type of communication channel (I.E. protocol or encryption strength)

It doesn’t take a Doc Brown to write in ALFA

While XACML is indeed a comprehensive and powerful tech, its syntax can become a tad unwieldy at times. Who loves angle brackets after all? In comes the Abbreviated Language for Authorization also known as ALFA. ALFA is a developer-oriented policy syntax that is similar in its design to languages like Java or C# and is constrained to authorization use cases. It uses and maps directly to XACML’s structure.

The goal with ALFA is to make sure even non-technical users can read it all the while letting developers write policies (think “policy-as-code”) alongside their application code.

policy accounts {
    target clause Attributes.objectType==“account”
    apply firstApplicable
    rule consumerViewOwnAccount {
        target clause Attributes.actionId==“view”
        permit
        condition user.identity==account.owner
        }
    }

Copy

Great Scott! The power of attributes

With ABAC, each policy requirement is like a calculated leap through time. The organization, for example, can create policies to ensure that employees access only the information they’re cleared for, during appropriate times.

For instance:

Senior personnel with top-secret clearance can edit classified records if they’re assigned to the project, employed, and properly trained.
Junior personnel can view certain information only during specific hours.

Once policies are written, they’re deployed to a Policy Decision Point (PDP) that determines access, just like the DeLorean’s onboard systems keep travelers on course. To ensure accuracy, policies undergo rigorous testing to confirm they achieve desired access control — without any “side effects” or unintended data access.

ABAC implementation

A DeLorean without gasoline or a Mr. Fusion Home Energy Center wouldn’t go very far. It’s the same with a PDP without attributes.

This is where Policy Information Points (PIP), also known as “attribute connectors”, come into play. When the PDP receives a request from the PEP (e.g. “Can Marty play guitar at the prom?”), it can retrieve necessary information from the underlying PIP (e.g. How old is Marty? Does he have a business license? Can he play the guitar?)

That metadata is necessary for the PDP to reach a conclusion based on the policy it’s been configured with. For example, a licensed guitar player above 18 can play at Hill Valley HS’s prom or only seniors can play at Hill Valley High School’s prom.

Testing the time leap

Last but not least, we might want to validate policies. Are they correct? Do they have any gaps? Do they contradict one another? Use the PDP’s APIs as well as the Contextual Authorization Query (CAQ) to test the policies and even implement access reviews.

CAQ requests can be:

User-centric: What can Alice do?
Resource-centric: Who can access document #123?
Action-centric: Who can delete (anything)?
Context-centric: What can happen at 3am? What can a user from a banned country access?
A mix: What can Alice do on document #123?

Requests can be broad or narrow:

What can happen?
What can Alice do on document #123 from a corporate device?

Requests can be specific to an identity or based on generic attributes:

What can Alice do? vs. What can a manager do?
Who can edit document #21? vs. Who can edit documents that belong to the sales department?

CAQ are a compliance manager’s (and a tester’s) best friend.

Taking control: Back to the future

With ABAC, access control isn’t stuck in the past, weighed down by rigid roles and static permissions. Instead, it’s a bold leap into the future, where dynamic attributes ensure precise and secure data access at every turn.

Its policy-driven framework and dynamic attribute evaluation not only keeps ABAC up with today’s challenges — it anticipates and adapts to tomorrow’s.

It’s access control that’s ready to accelerate your organization to 88 miles per hour and beyond.

Sabrina Barkdoll